Java Reference
In-Depth Information
HTTP session state memory
Pay attention to the way that HTTP session state is managed in an application. HTTP session
data is usually long-lived, so it is quite easy to fill the heap up with session state data. That
leads to the usual issues when GC needs to run too frequently. (In addition, recall from
Chapter 7 that the more live data that exists in the heap, the longer each individual GC
takes.)
This is best dealt with at an application level: think carefully before deciding to store
something in the HTTP session. If the data can be easily re-created, it is probably best left
out of the session state. Also be aware of how long the session state is kept around. This
value is stored in the web.xml file for an application and defaults to 30 minutes:
<session-timeout>30</session-timeout>
That's a long time to keep session data around—is a user really expected to return after a
29-minute absence? Reducing that value can definitely mitigate the heap impact of having
too much session data.
This is an area where the implementation of the Java EE application server can help. Al-
though the session data must be available for 30 minutes (or whatever value is specified), the
data doesn't necessarily have to remain in the Java heap. The application server can move
the session data (by serializing it) to disk or a remote cache—say, maybe after 10 minutes of
idle time. That frees up space within the application server's heap and still fulfills the con-
tract with the application to save the state for 30 minutes. If the user does come back after 29
minutes, her first request might take a little longer as the state is read back from disk, but
overall performance of the application server will have been better in the meantime.
This is also an important principle to keep in mind while testing: what is the realistic expect-
ation for session management among the users of the application? Do they log in once in the
morning and use that session all day? Do they come and go frequently, leaving lots of aban-
doned sessions on the server? Something in between? Whatever the answer is, make sure that
testing scenario reflects the expected use of the session. Otherwise, the production server will
be ill-tuned, since its heap will be utilized in a completely different way than the perform-
ance tests measured.
Load generators have different ways of managing sessions, but in general there will be an
option to start a new session at certain points of the testing (which is accomplished by clos-
ing the socket connection to the server and discarding all previous cookies). In the tests
throughout this topic using fhb , a single session is maintained throughout each test for each
Search WWH ::




Custom Search