tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Len Popp" <len.p...@gmail.com>
Subject Re: Keeping busy site responsive
Date Thu, 28 Jun 2007 16:52:07 GMT
I was referring to users repeatedly reloading the web page (which is
done by pressing the F5 key, usually). It seems that some people will
sit there for minutes at a time reloading the same page over & over &
over, waiting for the server to come back up. That can make an
overload situation worse. Some web sites try to reduce those futile
page requests by redirecting to a static page which has a message
explaining that re-loading the page is pointless.

I don't know for sure whether that significantly reduces the number of
useless requests, but some web admins apparently think it does.
-- 
Len


On 6/28/07, Parham, Clinton <cparham@biosignia.com> wrote:
> Thank you everyone for your input so far.
>
> Brantley: I like the idea but the part about 'staggering to a halt
> issuing redirects' is a concern. If this were to happen, then even users
> with established sessions would have trouble getting through - right? I
> think the same applies to Tracey's suggestion.
>
> Maybe Christopher is on the right track where some sort of load balancer
> is the best solution. One that's smart enough to allow established
> sessions through and maybe redirect new ones while the server is at peak
> load. This would avoid Tomcat from having to deal with traffic it cannot
> handle/trying to issue redirects.
>
> Does anyone have any experience/recommendations setting something like
> this up? Len hinted at F5 - not sure we can afford that... Len: which F5
> and how much??
>
> -----Original Message-----
> From: Brantley Hobbs [mailto:sbhobbs@uga.edu]
> Sent: Wednesday, June 27, 2007 1:37 PM
> To: Tomcat Users List
> Subject: Re: Keeping busy site responsive
>
> Clinton,
>
> I implemented this as a filter/listener combination.
>
> The listener tracks session initialized events and increments an atomic
> Integer (decrementing it at session destroyed), saving it as a context
> attribute.
>
> The filter uses the following logic:
>
> 1.  If we're less than or equal to the number of allowed sessions, allow
> this one through.
> 2.  If we've exceeded the limit, check to see if this user already has
> an established session (using the request's getSession(false) call).  If
> they have an established session, allow them through.
> 3.  If they don't match either of the above, send them a redirect to a
> page letting them know to try back later.
>
> This approach seems to work well (at least until the box staggers to a
> halt simply issuing redirects).  I've hit a box with numbers that are at
> least double what the limit is and the people that have established
> sessions don't notice a thing.  Because it's simple filters and
> listeners, it should be fairly portable. I've attached the source with
> this mail.  There might be a couple of dependancies you can get rid of
> (like our log manager class), but it should be pretty easy to drop in.
>
> Hope this helps.
>
> B.
>
> Parham, Clinton wrote:
> > Tomcat Experts:
> >
> > How do I keep my web application responsive for users already half way
>
> > through an enrollment process when traffic volume is high?
> >
> > Here's the scenario: I have a set of 5 web pages that users must work
> > through to successfully enroll themselves. Assume the server can
> > handle 250 concurrent requests (maxThreads). While traffic volume is
> > under 250, enrollments complete normally. But once volume exceeds 250
> > and saturates the acceptCount/backlog queue, users half way through
> > enrollments cannot complete their enrollment (connections are refused)
>
> > because new users keep bombarding the site.
> >
> > What would be acceptable is for new users to see a 'site is busy
> > message' while enrollments in progress are completed. As enrollments
> > complete and concurrent threads drop below 250, new users are allowed
> > through.
> >
> > I have already considered maxActiveSessions but I don't think this
> > will solve the problem. If maxThreads is reached and the
> > acceptCount/backlog queue is exhausted, then the users with active
> > sessions and already partly through enrollment won't be able to get
> > back in to the site to complete their enrollment - right?
> >
> > Adding more servers to handle the load is not preferred because most
> > of the time they will be underutilized. Enrollments that experience
> > high traffic don't happen that often but when they do, we need to
> > support them.
> >
> > Thank you for your time.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
> > e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message