Since writing a post (here) on in-memory session count, I have been doing endless amounts of work on sessions, tracing them to see how the reaper script works as well as how frequently it runs.
One of the big issues we were facing is the number of in memory sessions we were creating. Due to memory limitations and an app that was creating large sessions we have limited number of sessions available so understanding the ins and outs of session management has been useful.
In front of our IHS and WAS servers we had a load balancer that was firing a request through to the front screen of the logon to see if the application we up and running. Getting the load balancer to test a static page on the web servers wasn't sufficient for our requirements. Given the frequency of the LB requests though and the fact every time they accessed the front page they were allocating a session, it would mean we would often end up with overflowed sessions.
Instead of hitting the app front page we tried to hit a simple jsp within the app but then WAS would create a session for that request rather than anything explicit in the application. After a bit of digging I found a line of code I could add to a jsp
<%@page session="false" %>
This also means the stats I was producing in my previous post were more accurate and did not inclue the LB requests in the session count!
Subscribe to:
Post Comments (Atom)
I am a little confused on this statement below:
ReplyDeleteIn front of our IHS and WAS servers we had a load balancer that was firing a request through to the front screen of the logon to see if the application we up and running. Getting the load balancer to test a static page on the web servers wasn't sufficient for our requirements.
What other possible requirement could you have that testing the static page on your web server is not a sufficient enough test for the load balancer to know if you web server is up or down? Why would the load balancer have to know if the application is up or down. Wouldn't the plugin handle that?
Hi Joel
ReplyDeleteYou are right the web server would handle if the app server was down. The LB requests are for when all the app servers are down.
In that case the web server would serve an error page. Although we can serve a custom page, our business users decided this wasn't enough and they couldn't wait for someone to spot the problem and then bring the app servers back online.
In the scenario where all the app servers are down (very unlikely but we have to cater for it), the LB would then be able to spot this and redirect all requests to our contingent site (we runa active/active) so hopefully any outage would be brief and not affect too many users.
John