Struts and Sessions

[Colin Wilson-Salt <co...@london.virgin.net>]

Would it be possible to make the use of sessions in Struts optional?

I'm concerned about the resource overhead if we have a lot of people visiting just a
few pages in our site.

We already build applications using the same kind of patterns that Struts uses, but
it would be nice to have the benefits of the formalised structure that Struts gives.

On the other hand, does anyone have any evidence that the resource overhead of
sessions is something I shouldn't be concernced about?

RE: Struts and Sessions

[Kevin Duffey <kd...@buymedia.com>]

Bravo! Awesome explanation Craig.

I would like to add a bit on how to get around the performance issue.. at
least in one way.

I have bragged alot about Orion app server, and for good reason. Not only is
it a full J2EE app server, not only is it VERY fast at returning JSP pages
(dynamic pages), but it also is a full featured clusterable server, all for
the low price of $1500 per server. So let me give you a simple diagram of
what I saw a lot of at JavaOne on how web-apps (and hardware) is being set
up.

Oh..and this is off topic a little bit..so I apologize, but there seems to
be a lot of interest in the performance issue with sessions, so if you find
this way off topic, delete it. :)

The 3-tier setup includes a front-end servlet container cluster, the
middle-tier ejb cluster, and the back end database cluster. App servers only
worry about the first two, but provide APIs to handle connection pooling and
the sorts for the back-end cluster. JDBC 2.0 makes it nice with DataSources
and all that good stuff.

A typical front-end cluster for fail-over and load-balancing would consist
of a load-balancer that feeds two servers. Now..I am not a hardware pro so I
don't know exactly how this is set up at this time..but I do know you need
something that can evenly feed the two (or more) servers in the front-end
cluster. This can be another machine with software load-balancing, or for
less money and more performance a good Cisco load balancer will do the
trick.

Because Orion is so cheap, and it has a license per server, you can put dual
or quad cpu servers on the front end and pay the same price for Orion. Now,
my company is deiciding between weblogic, silverstream, etc..and the
cheapest I have seen is $15K per cpu. We have decided to use single-cpu 1Ghz
systems with 1GB memory for our front-end servlet cluster, and probably the
same for our EJB cluster.

What I am getting at with all this is that you can "easily" (albeit a bit
more money) set up a cluster of servers to handle more clients (and more
sessions) using Orion clustering. With the use of WebLogic, JRUN 3.0 and
others, it will cost us about $250,000 to setup the hardware we want to use
for fail-over, load-balancing, etc. Most of that cost is the app server
licensing. With Orion, if you figure about $6000 per server (again, 1Ghz,
SCSI III, 1GB memory, Dell rack-mount systems) and $1500 per license, you
look at about $7500 for each server, or $15K for a two-server cluster with
load-balancing and fail-over. Plus your load-balance..a good hardware Cisco
runs about $5K to $10K. I wont get into back-end database cost..thats a
separate issue.

Point here is that by using Orion you can cheaply set up a clusterable
system with great performance and plenty of memory and ability to handle
1000's of users.

Now I say its cheap, loosely because if I were to start my own company, I
surely wouldn't be able to afford $50K in a full hardware setup..but $50K is
feasible with Orion, where as most other app servers I have seen it would
cost in to the $100K's mark.

At any rate..my goal here is to point out that there are solutions to allow
better performance. As far as I can tell, one server with 1GB memory should
be able to handle 1000's of users. Somebody correct me if I am wrong, but I
believe the "hashtable's" used by the HttpSession store references to
objects..and not the full object themselves. As Craig said..when your done
with it..remove the object so its gc'd and you should be able to handle alot
more users.


Anyways..I am ranting..sorry for the off-topic, but this is what I have been
going over in our company for some time now as well. We have the mentality
that if its too slow..throw more hardware at it, and while that is not
always the best thing to do..that is what clustering allows you to do. I
believe that is why it came about..to allow vertical growth of a server farm
to handle more clients at one time.


<snip>

>garbage collected.  There's no reason to keep it around any
> longer than that.
>
> Hashtables have the nice property that they support keyed access
> to even large numbers
> of objects with fairly linear response times.  Thus, it makes
> almost no difference (from
> a CPU time point of view) how many active sessions there are, or
> how many session scope
> beans you have in a particular sesison.
>
> In general, you will run into performance issues on your database
> and network long
> before you run out of CPU time -- unless your app is particularly
> CPU-intensive, so your
> mileage may vary.
>
> The bottom line -- if you don't need to maintain any state
> information across requests
> from the same user, you don't need sessions.  If you do need
> this, sessions are a pretty
> cheap way to meet that need.  What you need to do is plan the
> memory requirements
> appropriately (peak # of active sessions * peak memory for
> session scope beans, if you
> want to be conservative).
>
> Craig McClanahan
>
>
>
>
>

RE: Struts and Sessions

[Kevin Duffey <kd...@buymedia.com>]

It knows based on the first request sent to it. In the HttpServletRequest,
there is a header that must indicate if it supports it..or maybe Orion
"writes" a small response or something. I am not sure how it does it. I just
know it does it. If you turn cookies off, and you use Orion, you'll start
seeing a ?jsessionid=A23409ua or something like that. The jsessionid
parameter is the standard cookie session id name, and the value after it is
a server geneated session id value that Orion uses to find the session for
the same user.


> -----Original Message-----
> From: Colin Wilson-Salt [mailto:colin@london.virgin.net]
> Sent: Tuesday, June 27, 2000 11:44 AM
> To: struts-user@jakarta.apache.org
> Subject: Re: Struts and Sessions
>
>
> But, how does it know?
>
> Kevin Duffey wrote:
>
> > Hi,
> >
> > > If I want to support sessions on these devices, I have to
> resort to old
> > > tricks like URL rewriting etc. Can Struts give me any help here, maybe
> > > through its custom tags, to create URL rewritten links, and what
> > > should I do
> > > about forms.
> >
> > I don't know about other app servers, but Orion automatically uses URL
> > Rewriting if the browser doesn't support cookies. You don't have to do
> > anything to get the benefit. For what its worth..
>
>

Re: Struts and Sessions

[Colin Wilson-Salt <co...@london.virgin.net>]

But, how does it know?

Kevin Duffey wrote:

> Hi,
>
> > If I want to support sessions on these devices, I have to resort to old
> > tricks like URL rewriting etc. Can Struts give me any help here, maybe
> > through its custom tags, to create URL rewritten links, and what
> > should I do
> > about forms.
>
> I don't know about other app servers, but Orion automatically uses URL
> Rewriting if the browser doesn't support cookies. You don't have to do
> anything to get the benefit. For what its worth..

RE: Struts and Sessions

[Kevin Duffey <kd...@buymedia.com>]

Hi,

> If I want to support sessions on these devices, I have to resort to old
> tricks like URL rewriting etc. Can Struts give me any help here, maybe
> through its custom tags, to create URL rewritten links, and what
> should I do
> about forms.

I don't know about other app servers, but Orion automatically uses URL
Rewriting if the browser doesn't support cookies. You don't have to do
anything to get the benefit. For what its worth..

RE: Struts and Sessions

[Colin Wilson-Salt <co...@london.virgin.net>]

I think you've covered the issues of resource use by sessions quite well.
However, there a just a couple of points that I can think of:

In my experience, coders are often slack about removing stuff from sessions,
so sessions tend to grow.

Also the correct use of sessions needs to be stressed, I feel they should
only be used for stuff that needs to held for a while. I feel that request
scope should be used for things which are only displayed on the resulting
page.

This is why in my code I have always used Request scope for my equivalent of
Strut's ActionForm. Sure, a new form bean gets constructed everytime the
user iterates around the form, but most of the time users get it right first
time.

I have to deal with devices that don't support cookies. But the usage
pattern on these devices tends to be a very short sequence of requests -
people looking for very specific information, rather than browsing.

If I want to support sessions on these devices, I have to resort to old
tricks like URL rewriting etc. Can Struts give me any help here, maybe
through its custom tags, to create URL rewritten links, and what should I do
about forms.

I know this has strayed away from Struts, and into more general servlet
programming issues. I hope people don't mind.

-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: 26 June 2000 18:58
To: struts-user@jakarta.apache.org
Subject: Re: Struts and Sessions


Colin Wilson-Salt wrote:

> Would it be possible to make the use of sessions in Struts optional?
>
> I'm concerned about the resource overhead if we have a lot of people
visiting just a
> few pages in our site.
>
> We already build applications using the same kind of patterns that Struts
uses, but
> it would be nice to have the benefits of the formalised structure that
Struts gives.
>
> On the other hand, does anyone have any evidence that the resource
overhead of
> sessions is something I shouldn't be concernced about?

There are a couple of issues raised here (and in the follow-ups) to be
addressed:


(1) Can I Use Struts Without Sessions?

Using the basic MVC controller servlet without sessions is certainly
feasible.  But it
is worth looking at what Struts uses sessions for, and therefore what you
give up
without them.

The background for this discussion is the fact that HTTP is a stateless
protocol.  In
other words, there is absolutely nothing provided by the protocol itself
that ties one
request from a particular user to the next request from that same user.
(Just as an
example, some people assume that they can use the remote IP address to make
this
distinction, but that doesn't work when your users are behind a firewall and
they all
appear to have the same IP address, or if you have multiple users running
off the same
server.)  The session management capability in the servlet API provides a
mechanism for
establishing this kind of connection between requests, and requires sending
the client
an identifier (using either cookies or URL rewriting) that the client can
send back on
the next request.

In Struts specifically, the following uses are made of sessions:

* You can store the ActionForm bean in the session or the request.
  If your bean supports multi-page input, session is the only way
  to save the values from the previous page(s).  For single page
  forms, request scope works fine.

* Struts expects a per-user Locale to represent the users's choice
  of language and display styles for internationalized messages.
  Generally, if this object is not present, the server's default Locale
  will be used.

In web applications based on servlets and JSP pages in general (including
those based on
Struts), you also have the following issues to think about:

* By default, JSP pages assume that they are part of a session.
  If you don't want this, you have to put the following code at the
  top of every single page:

    <%@ page ... session="false" ... %>

* Many applications perform their own authentication and login
  to make sure that only validated users can access certain
  parts of the application.  The usual mechanism for doing this is
  to store some sort of user object in the user's session -- if you
  detect that this object is missing (because the user tried to jump
  into the middle of your app without logging in, or because their
  previous session timed out), you force them to the login page.
  Without sessions, this will be very difficult to implement
  in a robust manner.

* Without sessions, you are limited to transactions that can be
  completed solely based on the request parameters of a single
  individual request, since you have no way to link more than one
  request together.

* Many sites like to personalize the appearance of their apps
  based on who the user is, or what preferences they have saved.
  Beyond the authentication issue mentioned earlier, most such
  apps save the user's current preferences in a session variable
  to save having to go back to the database every request.  This can
  be a significant performance impact.

So are sessions worth it?  Well, that depends on the cost, as we'll see in
the next
question ....


(2) What Are The Performance Impacts of Sessions?

If you have looked at very many of the Java "standard extensions" APIs, you
will note
that most of them define Java interfaces (and associated contracts
documented in the
spec and the Javadocs) that a particular implementation of that API must
conform to, but
they give the implementers a fair degree of freedom in *how* to conform to
the
requirements.  Thus, there is no general answer to the question "how does a
servlet
container implement the HttpSession interface."

However, it is worthwhile looking at the way Tomcat handles this -- most of
the
containers I'm familiar with do something similar.

Inside of Tomcat, the set of active sessions associated with a part of a web
application
are instances of the class org.apache.tomcat.session.StandardSession, which
has a few
small instance variables and a Hashtable to contain the user's session
beans.  For a
session with no session attributes, this is probably something on the order
of 50 bytes
of memory usage in the JVM's heap (why no precise answer?  well, it depends
on the
implementation of the JVM ....).  Tomcat also maintains a Hashtable of all
the active
sessions at any given point in time, inside a component called the
"Manager".

Individual sessions can store any number of session-scoped beans (JSP
terminology).  The
memory occupancy of those beans is totally dependent on the instance
variables in that
bean (there's only one memory copy of the bytecodes of any class in Java, so
how much
code there is has almost zero impact).  Note that you, as the developer,
have total
control over adding and *removing* these objects.  For example, as soon as
you are done
with a particular ActionForm bean in a Struts application, you should remove
it from the
session (in the Action class that received the final copy of the form) so
that it can be
garbage collected.  There's no reason to keep it around any longer than
that.

Hashtables have the nice property that they support keyed access to even
large numbers
of objects with fairly linear response times.  Thus, it makes almost no
difference (from
a CPU time point of view) how many active sessions there are, or how many
session scope
beans you have in a particular sesison.

In general, you will run into performance issues on your database and
network long
before you run out of CPU time -- unless your app is particularly
CPU-intensive, so your
mileage may vary.

The bottom line -- if you don't need to maintain any state information
across requests
from the same user, you don't need sessions.  If you do need this, sessions
are a pretty
cheap way to meet that need.  What you need to do is plan the memory
requirements
appropriately (peak # of active sessions * peak memory for session scope
beans, if you
want to be conservative).

Craig McClanahan

Re: Struts and Sessions

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Colin Wilson-Salt wrote:

> Would it be possible to make the use of sessions in Struts optional?
>
> I'm concerned about the resource overhead if we have a lot of people visiting just a
> few pages in our site.
>
> We already build applications using the same kind of patterns that Struts uses, but
> it would be nice to have the benefits of the formalised structure that Struts gives.
>
> On the other hand, does anyone have any evidence that the resource overhead of
> sessions is something I shouldn't be concernced about?

There are a couple of issues raised here (and in the follow-ups) to be addressed:


(1) Can I Use Struts Without Sessions?

Using the basic MVC controller servlet without sessions is certainly feasible.  But it
is worth looking at what Struts uses sessions for, and therefore what you give up
without them.

The background for this discussion is the fact that HTTP is a stateless protocol.  In
other words, there is absolutely nothing provided by the protocol itself that ties one
request from a particular user to the next request from that same user.  (Just as an
example, some people assume that they can use the remote IP address to make this
distinction, but that doesn't work when your users are behind a firewall and they all
appear to have the same IP address, or if you have multiple users running off the same
server.)  The session management capability in the servlet API provides a mechanism for
establishing this kind of connection between requests, and requires sending the client
an identifier (using either cookies or URL rewriting) that the client can send back on
the next request.

In Struts specifically, the following uses are made of sessions:

* You can store the ActionForm bean in the session or the request.
  If your bean supports multi-page input, session is the only way
  to save the values from the previous page(s).  For single page
  forms, request scope works fine.

* Struts expects a per-user Locale to represent the users's choice
  of language and display styles for internationalized messages.
  Generally, if this object is not present, the server's default Locale
  will be used.

In web applications based on servlets and JSP pages in general (including those based on
Struts), you also have the following issues to think about:

* By default, JSP pages assume that they are part of a session.
  If you don't want this, you have to put the following code at the
  top of every single page:

    <%@ page ... session="false" ... %>

* Many applications perform their own authentication and login
  to make sure that only validated users can access certain
  parts of the application.  The usual mechanism for doing this is
  to store some sort of user object in the user's session -- if you
  detect that this object is missing (because the user tried to jump
  into the middle of your app without logging in, or because their
  previous session timed out), you force them to the login page.
  Without sessions, this will be very difficult to implement
  in a robust manner.

* Without sessions, you are limited to transactions that can be
  completed solely based on the request parameters of a single
  individual request, since you have no way to link more than one
  request together.

* Many sites like to personalize the appearance of their apps
  based on who the user is, or what preferences they have saved.
  Beyond the authentication issue mentioned earlier, most such
  apps save the user's current preferences in a session variable
  to save having to go back to the database every request.  This can
  be a significant performance impact.

So are sessions worth it?  Well, that depends on the cost, as we'll see in the next
question ....


(2) What Are The Performance Impacts of Sessions?

If you have looked at very many of the Java "standard extensions" APIs, you will note
that most of them define Java interfaces (and associated contracts documented in the
spec and the Javadocs) that a particular implementation of that API must conform to, but
they give the implementers a fair degree of freedom in *how* to conform to the
requirements.  Thus, there is no general answer to the question "how does a servlet
container implement the HttpSession interface."

However, it is worthwhile looking at the way Tomcat handles this -- most of the
containers I'm familiar with do something similar.

Inside of Tomcat, the set of active sessions associated with a part of a web application
are instances of the class org.apache.tomcat.session.StandardSession, which has a few
small instance variables and a Hashtable to contain the user's session beans.  For a
session with no session attributes, this is probably something on the order of 50 bytes
of memory usage in the JVM's heap (why no precise answer?  well, it depends on the
implementation of the JVM ....).  Tomcat also maintains a Hashtable of all the active
sessions at any given point in time, inside a component called the "Manager".

Individual sessions can store any number of session-scoped beans (JSP terminology).  The
memory occupancy of those beans is totally dependent on the instance variables in that
bean (there's only one memory copy of the bytecodes of any class in Java, so how much
code there is has almost zero impact).  Note that you, as the developer, have total
control over adding and *removing* these objects.  For example, as soon as you are done
with a particular ActionForm bean in a Struts application, you should remove it from the
session (in the Action class that received the final copy of the form) so that it can be
garbage collected.  There's no reason to keep it around any longer than that.

Hashtables have the nice property that they support keyed access to even large numbers
of objects with fairly linear response times.  Thus, it makes almost no difference (from
a CPU time point of view) how many active sessions there are, or how many session scope
beans you have in a particular sesison.

In general, you will run into performance issues on your database and network long
before you run out of CPU time -- unless your app is particularly CPU-intensive, so your
mileage may vary.

The bottom line -- if you don't need to maintain any state information across requests
from the same user, you don't need sessions.  If you do need this, sessions are a pretty
cheap way to meet that need.  What you need to do is plan the memory requirements
appropriately (peak # of active sessions * peak memory for session scope beans, if you
want to be conservative).

Craig McClanahan