Sessions surely do impose a burden on the container.
If your servlet uses sessions, or if your JSP does not specify session="false", every visitor gets a session eating up a bit of memory. Memory requirements become directly proportional to load.Distributed containers share sessions between JVMs, meaning that session data is serialized over the network (often by storing it in a database, e.g. WebSphere). The overhead involved is proportional to both the number of sessions and the size of your session data; store more than 2-4KB of session data and performance under load sinks through the floor.A quick example: if your JVM has 1GB of memory allocated to it, half of this is available for session data with a 4KB footprint per session, sessions take half an hour to time out, and an average user spends 10 minutes on your site, you are memory-limited to 524,288/4 * 10/(10+30) = 32,768 simultaneous users per server. This is fine; CPU and I/O constraints are likely to limit you to 1,000 - 10,000 users per server anyway.
On the other hand, if you have only 128MB available for session data, you happily store 100KB worth of garbage in the session (don't laugh, I've seen this and worse), and users spend an average of 3 minutes on your site, you are memory-limited to 131,072/100 * 3/(3+30) = 119 users. You will run out of memory long before you run out of CPU or I/O bandwidth.
I should really add that these example assume that the container does not passivate sessions. If it does, in the last example, the container can passivate the session shortly after the user has left the site (3 mins) without impacting performance too much, improving scalability tenfold to about 1000 users. Memory would still represent a significant bottleneck though.
When building massively scalable sites or applications, avoid sessions as much as you can, time them out as quickly as you can, and aggressively invalidate them wherever you can.
- Peter
[ September 05, 2002: Message edited by: Peter den Haan ]