RE: Keeping busy site responsive
| From: Parham, Clinton [mailto:[EMAIL PROTECTED] | Sent: Thursday, 28 June, 2007 07:34 | | 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. If you set your threshold appropriately (based on your service rate) and go with my second "suggestion" (really phrased more as a question) of returning a 503 (Server Busy) status instead of issuing a redirect, I think you should be fine and it would require the least amount of work (I haven't actually looked at Brantley's code, but it sounds pretty straightforward). Although I do like Christopher's "gatekeeper" solution, as it could probably be leveraged to provide similar services for other applications as well. It could also be implemented as a simple CGI script, so you wouldn't have to have two machines (or even two instances of TC). If your front end is Apache with mod_perl configured, a pleasant evening playing with IPC would probably produce a decent solution - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping busy site responsive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clinton, Parham, Clinton wrote: > What you suggested initially was that one system be the traffic > controller and depending on how busy the enrollment server is, either > send users to it or redirect them to a static 'busy' page elsewhere. > How were you thinking this communication between the traffic > controller and enrollment server would work? The traffic controller and enrollment server can communicate by several means, including sharing a database (polling) or having a special communication channel that is not shared with outside users. For instance, a private web service hosted by the traffic controller that can accept "send one more client" messages from the enrollment server. > If I don't include the step of > checking state on the fly, don't I run the risk of the enrollment > server being flooded and preventing enrollments in progress from > completing? Not necessarily. You can have more than one connection queue. If you use multiple s, you can configure one to be public (this is the one that becomes saturated) and one to be private (the one to receive "ready" messages from the enrollment server). There are, of course, other ways to communicate between applications. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGhA4j9CaO5/Lv0PARAvtPAJ9WPEJQDdjzc0Wvp35LY3//WAxsMwCdEg9W Ics0Mfup1dzSxsKgk54jdaU= =HCjR -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping busy site responsive
Brantley, I will keep the filter in mind as a possibility but something tells me that keeping all that traffic away from the server where enrollments are in progress is probably a good thing. Yep, you're right about the F5 key :) Silly me! Thanks, Clinton -Original Message- From: Brantley Hobbs [mailto:[EMAIL PROTECTED] Sent: Thursday, June 28, 2007 10:16 AM To: Tomcat Users List Subject: Re: Keeping busy site responsive Clinton, I think it might be worth your trouble to find out what number it is that causes the box to "[stagger] to a halt issuing redirects". I started having network saturation on the little switch I was using for my test rig before the load started getting bad on the box. I don't have the exact numbers in front of me. I think Len was referring to the F5 key on your keyboard (it being the hotkey for the browser to refresh the page). One thing to keep in mind with a hardware load balancer to make this decision for you is that for it to know if you have an already established session it will need to examine the inbound request, AFAIK. If you're using SSL, you'll need a load-balancer capable of terminating the SSL connection. I really think it might be worth your while to simply try the filter first. B. Parham, Clinton 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:[EMAIL PROTECTED] > 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 reache
RE: Keeping busy site responsive
Chris, I guess what I was thinking about with load balancing is that I might have two Tomcat servers ready to process enrollments. I need some traffic controller in front of them to manage incoming traffic so they don't get swamped and unable to process enrollments already in progress. What you suggested initially was that one system be the traffic controller and depending on how busy the enrollment server is, either send users to it or redirect them to a static 'busy' page elsewhere. How were you thinking this communication between the traffic controller and enrollment server would work? I might be misunderstanding your suggestion: 'Why not skip the extra step of determining the state on the fly and just send the user to another server (permanently)?' If I don't include the step of checking state on the fly, don't I run the risk of the enrollment server being flooded and preventing enrollments in progress from completing? Thanks, Clinton -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Thursday, June 28, 2007 9:29 AM To: Tomcat Users List Subject: Re: Keeping busy site responsive -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clinton, Parham, Clinton wrote: > 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?? I don't think you need special lb hardware. Just use two machines (or even two TC instances on the same machine) and have one redirect users to the other. A single switch (the redirect) is all you require. Adding load balancing into the equation will just introduce new problems. Also, you're not trying to balance load. You're trying to send users in different states to different places. Why not skip the extra step of determining the state on the fly and just send the user to another server (permanently)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGg7eg9CaO5/Lv0PARAqZ8AJ0at0W/PPpmt0Hnm/9X18uzusQNWACfTy6S 2MsmHQWD43CBs1HgHJk95lk= =x7DV -END PGP SIGNATURE-
Re: Keeping busy site responsive
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping busy site responsive
Clinton, I think it might be worth your trouble to find out what number it is that causes the box to "[stagger] to a halt issuing redirects". I started having network saturation on the little switch I was using for my test rig before the load started getting bad on the box. I don't have the exact numbers in front of me. I think Len was referring to the F5 key on your keyboard (it being the hotkey for the browser to refresh the page). One thing to keep in mind with a hardware load balancer to make this decision for you is that for it to know if you have an already established session it will need to examine the inbound request, AFAIK. If you're using SSL, you'll need a load-balancer capable of terminating the SSL connection. I really think it might be worth your while to simply try the filter first. B. Parham, Clinton 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [E
Re: Keeping busy site responsive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clinton, Parham, Clinton wrote: > 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?? I don't think you need special lb hardware. Just use two machines (or even two TC instances on the same machine) and have one redirect users to the other. A single switch (the redirect) is all you require. Adding load balancing into the equation will just introduce new problems. Also, you're not trying to balance load. You're trying to send users in different states to different places. Why not skip the extra step of determining the state on the fly and just send the user to another server (permanently)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGg7eg9CaO5/Lv0PARAqZ8AJ0at0W/PPpmt0Hnm/9X18uzusQNWACfTy6S 2MsmHQWD43CBs1HgHJk95lk= =x7DV -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping busy site responsive
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping busy site responsive
On 6/27/07, Brantley Hobbs <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping busy site responsive
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:[EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping busy site responsive
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:[EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping busy site responsive
| From: Brantley Hobbs [mailto:[EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/*
* UserLimitFilter.java
*
* Created on May 11, 2007, 8:27 AM
*/
package edu.uga.asg.apojee.web.util;
import edu.uga.asg.apojee.logging.Log;
import edu.uga.asg.apojee.logging.LogManager;
import edu.uga.asg.apojee.logging.LogCategory;
import java.util.concurrent.atomic.AtomicInteger;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import javax.servlet.http.HttpSession;
/**
*
* A [EMAIL PROTECTED] Filter} which, in combination with the [EMAIL PROTECTED]
SessionCountListener},
* limits the number of active sessions for a context.
*
*
*
*
*
* Filter [EMAIL PROTECTED] init-param}s
*
*
* [EMAIL PROTECTED] param-name}
* [EMAIL PROTECTED] param-value} (example)
* Description
* Required?
* Default
*
*
*
*
* [EMAIL PROTECTED] enabled}
* false
* determines whether or not the filter is applied
* No
* true
*
*
* [EMAIL PROTECTED] redirectURL}
* http://www.google.com/search?hl=en&q=too+many+users
* the URL sent in a header redirect when the user limit is
exceeded
* Yes
* N/A
*
*
* [EMAIL PROTECTED] userLimit}
* 50
* the maximum number of active sessions that may exist at one
time
* Yes
* N/A
*
*
*
*
* @author Brantley Hobbs (UGA ASG)
* @since APOJEE Core 1.0.1
*/
public class UserLimitFilter implements Filter {
private static final Log log =
LogManager.getLog(LogCategory.APPLICATION);
private String className = this.getClass().getName();
private boolean enabled = true;
private String redirectURL = null;
private Integer userLimit = null;
/**
* Creates a new instance of [EMAIL PROTECTED] UserLimitFilter}.
RE: Keeping busy site responsive
| From: Parham, Clinton [mailto:[EMAIL PROTECTED] | 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping busy site responsive
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
