×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Nathan Andelin skrev:
From: Thorbjoern Ravn Andersen
Frequently it is too many idle sessions which must time out
to be reclaimed. First try lowering the session timeout value.
Could you expand on that? My Google search on session timeout values returned results for terminal services and other specific applications, but not Web Application Servers, generally.
Naturally.
Originally the http-servers were stateless meaning that there was no
concept of "this request goes to user A who was here just earlier etc".
Cookies was invented to get around that - it is basically a token
identifying a user. This has been used in many web frameworks to
implement sesisons, basically a memory structure for holding user
specific information across requests.
The problem with these sessions are:
1) the structure is in memory
2) a busy site may serve MANY sessions
3) users do not log out, they just stop clicking on the site
=> loaded webserver application needs LOTS of memory and eventually
crash or swap to death.
One way to approach this, is to kill idle sessions. The idle period is
what is referred to above as the "session timeout" value. A typical
value is 30 minutes. Lowering this, will help you somewhat but not much
when the load is intense.
Another approach used AFAIK in Apache Tomcat and other Java web servers
is to persist the oldest sessions to disk (basically freezing them) and
unfreezing them when the user comes back. This allows users to come
back the day after and still have their shopping cart items in their
cart. This is very nice and easily done in Java where objects can be
serialized to a file and unserialized back into an object.
But all this is just part of the solution. Basically a web application
must be built from the beginning to be scalable. The only way to be
sure it IS scalable is to do scalability tests. Otherwise your users
will be doing that when the system goes live and they are not very
forgiving.
Note that the scalability tests should simulate users, not programmers,
as programmers use the system nicely :)
Hope this clarifies things somewhat...
As an Amazon Associate we earn from qualifying purchases.