You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Parham, Clinton" <cp...@biosignia.com> on 2007/06/27 15:40:47 UTC

Keeping busy site responsive

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


Re: Keeping busy site responsive

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clinton,

Parham, Clinton wrote:
> How do I keep my web application responsive for users already half way
> through an enrollment process when traffic volume is high?

Depending on how far you want to go, you might be able to use one server
to accept connections and begin enrollments. Once the enrollment is
"started", you could hand the user off to another server where the real
enrollment work is done.

Meanwhile, newly arriving users (who have not yet started) queue up and
possibly timeout attempting to connect to the first server. Your
enrolling users continue through the process.

Once enrollment is complete, or maybe when their session dies (in case
of a session timeout), you can notify the queuing server that there's an
"opening" in the enrollment process, and another user can start the process.

This is sort of crude and requires additional hardware (or, at least a
separate server process), but will solve your problem of locking-out
users who you consider privileged.

Hope that helps,
- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGgm589CaO5/Lv0PARAiTVAJ4lxuJzs+Q0uramvMnZqj22ttuitACZARU7
t4WCdpYb39V2t0nCHopK4Xg=
=Fk3f
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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


Re: Keeping busy site responsive

Posted by Brantley Hobbs <sb...@uga.edu>.
I should say "an actual redirect response code could confuse a browser".

B.

Brantley Hobbs wrote:
> You know, I hadn't given it a lot of thought to be honest.
>
> I think that for accuracy's sake it should probably be a 500 error (I 
> assume that 503 is a server busy error or something; don't know it off 
> the top of my head).  An actual redirect error could confuse a browser.
>
> I'd assume that for optimal performance you'd want to redirect to 
> another machine, but there's nothing enforcing this.  If you're using 
> Apache or IIS as a localhost front-end, you could redirect to a URI 
> that's being served by the web server.  This is likely to be a 
> low-cost operation.
>
> Brantley
>
> Nelson, Tracy M. wrote:
>> | From: Brantley Hobbs [mailto:sbhobbs@uga.edu]
>> | Sent: Wednesday, 27 June, 2007 12:37
>> | | This approach seems to work well (at least until the box staggers 
>> to a
>> | halt simply issuing redirects).
>>
>> Just out of curiosity, do you think it would help in those situations to
>> issue a 503 instead of a 307?  Or do you redirect to another machine for
>> the busy page?
>> -----------------------------------------
>> ------------------------------------------------------------
>> The information contained in this message is confidential
>> proprietary property of Nelnet, Inc. and its affiliated companies 
>> (Nelnet) and is intended for the recipient only.
>> Any reproduction, forwarding, or copying without the express
>> permission of Nelnet is strictly prohibited. If you have
>> received this communication in error, please notify us
>> immediately by replying to this e-mail.
>> ------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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


Re: Keeping busy site responsive

Posted by Len Popp <le...@gmail.com>.
On 6/27/07, Brantley Hobbs <sb...@uga.edu> wrote:
> I'd assume that for optimal performance you'd want to redirect to
> another machine, but there's nothing enforcing this.  If you're using
> Apache or IIS as a localhost front-end, you could redirect to a URI
> that's being served by the web server.  This is likely to be a low-cost
> operation.

Redirecting to a static page even on the same machine can reduce the
server load, if the static page says "This is a static page. Don't
bother pounding on F5, you'll only get a blister."
-- 
Len

---------------------------------------------------------------------
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


Re: Keeping busy site responsive

Posted by Brantley Hobbs <sb...@uga.edu>.
You know, I hadn't given it a lot of thought to be honest.

I think that for accuracy's sake it should probably be a 500 error (I 
assume that 503 is a server busy error or something; don't know it off 
the top of my head).  An actual redirect error could confuse a browser.

I'd assume that for optimal performance you'd want to redirect to 
another machine, but there's nothing enforcing this.  If you're using 
Apache or IIS as a localhost front-end, you could redirect to a URI 
that's being served by the web server.  This is likely to be a low-cost 
operation.

Brantley

Nelson, Tracy M. wrote:
> | From: Brantley Hobbs [mailto:sbhobbs@uga.edu]
> | Sent: Wednesday, 27 June, 2007 12:37
> | 
> | This approach seems to work well (at least until the box staggers to a
> | halt simply issuing redirects).
>
> Just out of curiosity, do you think it would help in those situations to
> issue a 503 instead of a 307?  Or do you redirect to another machine for
> the busy page?
> -----------------------------------------
> ------------------------------------------------------------
> The information contained in this message is confidential
> proprietary property of Nelnet, Inc. and its affiliated 
> companies (Nelnet) and is intended for the recipient only.
> Any reproduction, forwarding, or copying without the express
> permission of Nelnet is strictly prohibited. If you have
> received this communication in error, please notify us
> immediately by replying to this e-mail.
> ------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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


RE: Keeping busy site responsive

Posted by "Nelson, Tracy M." <Tr...@nelnet.net>.
| From: Brantley Hobbs [mailto:sbhobbs@uga.edu]
| Sent: Wednesday, 27 June, 2007 12:37
| 
| This approach seems to work well (at least until the box staggers to a
| halt simply issuing redirects).

Just out of curiosity, do you think it would help in those situations to
issue a 503 instead of a 307?  Or do you redirect to another machine for
the busy page?
-----------------------------------------
------------------------------------------------------------
The information contained in this message is confidential
proprietary property of Nelnet, Inc. and its affiliated 
companies (Nelnet) and is intended for the recipient only.
Any reproduction, forwarding, or copying without the express
permission of Nelnet is strictly prohibited. If you have
received this communication in error, please notify us
immediately by replying to this e-mail.
------------------------------------------------------------

---------------------------------------------------------------------
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


Re: Keeping busy site responsive

Posted by Brantley Hobbs <sb...@uga.edu>.
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
>
>   

RE: Keeping busy site responsive

Posted by "Nelson, Tracy M." <Tr...@nelnet.net>.
| From: Parham, Clinton [mailto:cparham@biosignia.com]
| Sent: Wednesday, 27 June, 2007 08:41
| 
| How do I keep my web application responsive for users already half way
| through an enrollment process when traffic volume is high?

I'd recommend setting a "registration-in-progress" session cookie.
Then, add a check on the first page of your process; obviously anyone
requesting pages 2-5 already has completed page 1 (I assume you have
some kind of check that assures this, and redirects them to page 1 if
they haven't).  If the load is low, set the cookie and continue
processing; otherwise redirect to the "Server busy -- try again later"
page.
 
Not being a Tomcat expert, I don't know how you can get the current
session count, but I'm guessing it'd be more efficient to set some kind
of indicator, and use that instead of re-querying it with every request.
Either have a separate thread that re-checks every N minutes, or just
keep a request counter of some sort and re-check every N requests.
Hmmm, I seem to be pointing out the obvious now, so I'll be quiet....
-----------------------------------------
------------------------------------------------------------
The information contained in this message is confidential
proprietary property of Nelnet, Inc. and its affiliated 
companies (Nelnet) and is intended for the recipient only.
Any reproduction, forwarding, or copying without the express
permission of Nelnet is strictly prohibited. If you have
received this communication in error, please notify us
immediately by replying to this e-mail.
------------------------------------------------------------

---------------------------------------------------------------------
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