Alan Hodgson wrote: > On Monday 21 September 2009, Scott Marlowe <scott.marlowe@xxxxxxxxx> 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? > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
