Alan Hodgson wrote:
> On Monday 21 September 2009, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> I'm looking at running session servers in ram.
>
> Use memcached for session data.
IMHO postgres is more appropriate for some types of session data.
One of the apps I work on involves session data that consists of
geospatial data which we store and index in postgres/postgis.
Scott Marlowe wrote:
> I'm looking at running session servers in ram.
> We're currently IO write bound with
> fsync=off using a 15k5 seagate SAS drive, so I'm hoping that moving
> the db into /dev/shm will help quite a bit here.
"a 15k5 seagate SAS drive"
Is this implying that you have "a" == one session server? I
bet that it'd be cheaper to throw a bunch of cheap boxes
in there and make a pool of session servers rather than one
fast one. When a new session is created, your application
code can then pick the least loaded session server and put
the session-server-number in a cookie.
This approach works fine for me - but I suspect I have many
fewer, yet probably much larger sessions going through the
system.
> Does anybody any real world experience here or any words of sage
> advice before I go off and start testing this?
>
