Performance tuning: lite sessions and local ServletContext

Question

I have been doing some research on iPlanet performance tuning. In our
current production environment (iAS6.0 SP1B, iWS4.1 SP2 on Solaris), since
we don't use clustering there should be a couple of performance improvements
we can make immediately:
1. Use lite sessions (<session-impl>lite</session-impl> in ias-web.xml) - I
believe that if you use lite sessions, the session data is stored in the kjs
process space as opposed to the kxs process space. This, of course, means
that if a kjs dies the user's on it will lose their session information but
it will provide a performance improvement by reducing kxs/kjs communication.
2. Use local ServletContexts (<distributable>false</distributable> in
web.xml) - This should cause the ServletContext to only be stored in the
originating JVM. So again, if a kjs dies, the user will lose their
ServletContext but again we will get a performance improvement by reducing
kxs/kjs communcation.
What I want to understand is how our load balancing configuration will
effect our production environment if we use this configuration. Right now
we use sticky load balancing on all our servlets but we don't have our JSPs
registered and therefore sticky load balancing cannot always be trusted to
return users to the iAS they came from. We make up for this by using
hardware load balancing that keeps the majority of our users sticky.
However, using lite sessions and local ServletContexts will require that a
user not only stick to an iAS, but to a specific kjs as well. Using sticky
load balancing would ensure that, but since we also rely on our hardware
load balancers, could they create a problem? If a user gets sent back to
the iAS they came from by our hardware load balancers, will the kxs process
be smart enough to return them to the kjs they came from? If so, then I
think that means that we can safely switch to lite sessions and local
ServletContexts, but if not, I think many users will lose their sessions.
Thanks,
Linc

Answer 1

Please follow thru this link for your answers
http://developer.iplanet.com/viewsource/char_tuningias/index.jsp
Thanks
Shital Patel
Lincoln wrote:
I have been doing some research on iPlanet performance tuning. In our
current production environment (iAS6.0 SP1B, iWS4.1 SP2 on Solaris), since
we don't use clustering there should be a couple of performance improvements
we can make immediately:
1. Use lite sessions (<session-impl>lite</session-impl> in ias-web.xml) - I
believe that if you use lite sessions, the session data is stored in the kjs
process space as opposed to the kxs process space. This, of course, means
that if a kjs dies the user's on it will lose their session information but
it will provide a performance improvement by reducing kxs/kjs communication.
2. Use local ServletContexts (<distributable>false</distributable> in
web.xml) - This should cause the ServletContext to only be stored in the
originating JVM. So again, if a kjs dies, the user will lose their
ServletContext but again we will get a performance improvement by reducing
kxs/kjs communcation.
What I want to understand is how our load balancing configuration will
effect our production environment if we use this configuration. Right now
we use sticky load balancing on all our servlets but we don't have our JSPs
registered and therefore sticky load balancing cannot always be trusted to
return users to the iAS they came from. We make up for this by using
hardware load balancing that keeps the majority of our users sticky.
However, using lite sessions and local ServletContexts will require that a
user not only stick to an iAS, but to a specific kjs as well. Using sticky
load balancing would ensure that, but since we also rely on our hardware
load balancers, could they create a problem? If a user gets sent back to
the iAS they came from by our hardware load balancers, will the kxs process
be smart enough to return them to the kjs they came from? If so, then I
think that means that we can safely switch to lite sessions and local
ServletContexts, but if not, I think many users will lose their sessions.
Thanks,
Linc