DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=pOrC3lvw5ZDBfR68sb/ESvwgN4rU7i9JSbe26XRYFQxbOoy40xnMRChyEfeGaMHUEKh/hy6cfhIbGBSpRVZTCEN4waCkoUjzrBi85bG0hOHaa3ecZHJO4p0buT8Fx9RLgeRxFw5AngNYEyggYdIhoCD8NcXqrE+fUgrOV6ECe4E=
Message-ID: <33c6269f050512070842df1af3@mail.gmail.com>
Date: Thu, 12 May 2005 10:08:09 -0400
From: Alex Turner <armtuk@gmail.com>
Reply-To: Alex Turner <armtuk@gmail.com>
To: PFC <lists@boutiquenumerique.com>
Subject: Re: Partitioning / Clustering
Cc: josh@agliodbs.com, David Roussel <pgsql-performance@diroussel.xsmail.com>,
	Alex Stapleton <alexs@advfn.com>, pgsql-performance@postgresql.org
In-Reply-To: <op.sqmuc2nnth1vuj@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <5F94B6EB-3925-4CD3-A67F-4310890B438A@advfn.com>
	<200505111013.52067.josh@agliodbs.com>
	<1115798277.29223.233869472@webmail.messagingengine.com>
	<op.sqmuc2nnth1vuj@localhost>

Having local sessions is unnesesary, and here is my logic:

Generaly most people have less than 100Mb of bandwidth to the internet.

If you make the assertion that you are transferring equal or less
session data between your session server (lets say an RDBMS) and the
app server than you are between the app server and the client, an out
of band 100Mb network for session information is plenty of bandwidth.=20
This also represents OLTP style traffic, which postgresql is pretty
good at.  You should easily be able to get over 100Tps.  100 hits per
second is an awful lot of traffic, more than any website I've managed
will ever see.

Why solve the complicated clustered sessions problem, when you don't
really need to?

Alex Turner
netEconomist

On 5/11/05, PFC <lists@boutiquenumerique.com> wrote:
>=20
>=20
> > However, memcached (and for us, pg_memcached) is an excellent way to
> > improve
> > horizontal scalability by taking disposable data (like session
> > information)
> > out of the database and putting it in protected RAM.
>=20
>         So, what is the advantage of such a system versus, say, a "sticky
> sessions" system where each session is assigned to ONE application server
> (not PHP then) which keeps it in RAM as native objects instead of
> serializing and deserializing it on each request ?
>         I'd say the sticky sessions should perform a lot better, and if o=
ne
> machine dies, only the sessions on this one are lost.
>         But of course you can't do it with PHP as you need an app server =
which
> can manage sessions. Potentially the savings are huge, though.
>=20
>         On Google, their distributed system spans a huge number of PCs an=
d it has
> redundancy, ie. individual PC failure is a normal thing and is a part of
> the system, it is handled gracefully. I read a paper on this matter, it's
> pretty impressive. The google filesystem has nothing to do with databases
> though, it's more a massive data store / streaming storage.
>=20
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>