10.4 Memory Usage
Considerations
You should be aware that all objects you save in the
application and session scopes take up memory in the server
process. It's easy to calculate how much memory is used for
the application scope because you have full control over the
number of objects you place there. But the total number of
objects in the session scope depends on the number of
concurrent sessions, so in addition to the size of each
object, you also need to know how many concurrent users you
have and how long a session lasts. Let's look at an example.
The CartBean used in this chapter is
small. It stores only references to ProductBean
instances, not copies of the beans. An object reference in
Java is 8 bytes, so with three products in the cart we need 24
bytes. The java.util.Vector object used to hold the
references adds some overhead, say 32 bytes. All in all, we
need 56 bytes per shopping cart bean with three products.
If this is a site with a modest amount of
customers, you may have 10 users shopping per hour. The
default timeout for a session is 30 minutes, so let's say that
at any given moment, you have 10 active users and another 10
sessions that aren't active but have not timed out yet. This
gives a total of 20 sessions times 56 bytes per session, a
total of 1,120 bytes. In other words, roughly 1 KB -- nothing
to worry about.
Now let's say your site becomes extremely
popular, with 2,000 customers per hour. Using the same method
to calculate the number of concurrent sessions as before, you
will have 4,000 sessions at 56 bytes; a total of roughly 220
KB -- still nothing to worry about. However, if you store
larger objects in each session, say the result of a database
search with an average size of 10 KB, it corresponds to
roughly 40 MB for 4,000 sessions. A lot more but still not
extreme, at least not for a site intended to handle this
amount of traffic. However, it should become apparent that
with that many users, you have to be a bit careful with how
you use the session scope.
Here are some things you can do to keep the
memory requirements under control:
-
Place only objects that really need to be
unique for each session in the session scope. In the
shopping cart example, each cart contains only references to
the product beans (not copies of the beans), and the catalog
bean and the product beans are shared by all users.
-
Set the timeout period for sessions to a
lower value than the default. If you know it's rare that
your users leave the site for 30 minutes and then return,
use a shorter period. You can change the timeout for all
sessions in an application through the application's
deployment descriptor (see Appendix
F), or by calling session.setMaxInactiveInterval(
) (see Appendix
D) in a custom action, bean, or servlet to change it for
an individual session.
-
Provide a way to end the session
explicitly. A good example is a logout function, or
invalidation of the session when something is completed (for
instance when an order form is submitted). In a JSP page,
you can use the <ora:invalidateSession>
custom action described in Chapter
12 to invalidate the session. In a servlet or other
custom code, you can use the HttpSession
invalidate( ) method, see Appendix
D. Invalidating a session makes all objects available
for garbage collection (the term used for when the Java
runtime removes unused objects to conserve memory).
We have covered a lot of ground in this
chapter, so lets recap the key points:
-
The scope concept gives you full control
over the lifetime and reach of shared information at a
convenient abstraction level. However, resist the temptation
to keep too much information around in the session scope.
-
Action elements for passing control between
pages, such as the standard <jsp:forward>
action and the JSTL <c:redirect> action,
allow you to allocate different roles to different pages,
and the JSTL <c:url> action can be used to
provide support for cookie-less session tracking.
The scope abstraction and the actions
together make it possible to develop JSP-based applications
that are easy to maintain and extend.
|