Session Data in Database vs in memory

[daroepie]

I'm building an e-commerce site that could see a lot of traffic (100+ simultaneous users, 10000 users a day). I'm keen to minimise the latency between requests and server responses and was thinking of putting all the user session data + basket data in memory instead of in MySQL.

I calculate approx. 256 bytes per session, and given a maximum of 10,000 sessions, I would only need to allocate <3MB of memory.

Pros:
* Fast access to session data
* Less database i/o for session data will speed up db i/o for searches/other queries

Cons:
* low-level implementation for speed (C/C++)
* memory fragmentation over long term use (perhaps)
* limited to 1 server

So what do you guys think? Is this a reasonable idea? I just want to avoid 100+ db hits every second.

Note, I am using the following:-
dual 244 opteron server + 2GB RAM
win2k3 IIS 6
ISAPI/C with some .NET for xml transforms

[plumsauce]

do you mean 100 hits/sec?

or, do you mean 100 users at a time,
with say 15 seconds think time between pages?

because that transforms into 400 page loads
per minute, or 400/60=6.6~ page loads/second

bear in mind that *MSSQL* caches data "hotspots"
and can cruise at this level all day without even
breathing hard.

a point to keep in mind is what about persistence
across reboots? returning customers?

raid 1/10 on scsi, i hope

+

[daroepie]

I meant 100+ simultaneous/concurrent requests so I was worried about the overhead of communicating with the database (either over Named Pipes or TCP/IP).

The server should run continuously so I hadn't factored in persistence between rebooots. I could perhaps store to db in case of reboots, or dump to file.

The caching of the db is an interesting point. I think I will have to benchmark the two methods to determine the practical difference in speeds.

((3x scsi in Raid 5 + 1 backup drive.))

[daroepie]

Oh yes, returning customers would need to log in, and for that I will definitely be hitting the db, primarily for persistence and for security.

But my thinking is that most people don't log in until the very end (at checkout).

[mrfori]

I'm not an expert but an idea can be create object of classes and store the object in session.

Depending on the language only the object reference will be stored in session instead of the whole data.

hope it helps .. correct me if i'm wrong

[bcc1234]

Depending on the language only the object reference will be stored in session instead of the whole data.

Data has to be stored somewhere, otherwise the reference is useless.

But unless you plan on running more than one server, you might want to keep everything in RAM and be done with it.
Let the OS swap when it needs to, it will probably be faster anyway.

One thing though, to have 100 concurrent pageviews for a regular e-commerce store, you would need much more than 10k daily visitors. Way more.

So if you are planning on having 10k visitors a day, and think that you need to handle 100 concurrent pageviews - you will overspend on your technology.

[daroepie]

Oh yes, apologies, it should have read 1,000,000 instead of 10,000. And strictly speaking, I should call them page views:

1,000,000 page views a day
42,000 / hour
700 / min
~10 / sec on average

But at peak hours, I could conceivably see a ten fold increase to 100+/sec (approx). With 15min session expiration, I think I only need to store around 10,000 sessions in RAM at any given moment.

I will have to benchmark this to get a clearer idea, but ultimately I think I will cache the most active sessions and let the db handle the others.

Thanks...

[chris_jt]

Bravo! That combined use of technology is what I use for a site getting about 2million hits a day... no problems. For the past 2 years there has been 100% up-time.

[JasonHamilton]

if you use php, you can set it to keep session data in memory instead of files, and store user's shopping carts into a session array.

I've had very good results with this - with everything being near instant and no database accessing.