tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32316] New: - Limiting new application sessions if load is to high
Date Fri, 19 Nov 2004 12:36:21 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32316>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32316

           Summary: Limiting new application sessions if load is to high
           Product: Tomcat 5
           Version: 5.0.30
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Native:JK
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: rainer.jung@kippdata.de


Limiting new application sessions if load is to high.

This enhancement should prevent complex systems from being flooded if some
backend system gets stuck or answers too slowly for some time. Users already
logged into an application might still be able to work successfully, but new
users get a very fast static response to prevent the incoming channels
(TCP-Connections, Threads, ...) from being flooded.

Implementation suggestion

Use a mod_jk-configurable start URL for the application (regexp based). If a
request X matches this URL, then mod_jk checks the scoreboard how many apache
requests are being processed simultaneously at that moment. There is a
configurable limit, and if that limit is reached, the request X will not be sent
to tomcat, but instead be answered by some configurable  "local" static response
(containing the info, that the load is to high and the user should try again
later). Alternatively one can configure X to be answered by some external redirect. 

Although the mechanism is for prevention of the application, counting tomcat
requests or counting all requests (inclusive static ones) does not really make a
difference according to our experiance. Static content usually serves in very
well under a second (depending mostly on internet speed). The idea here is to
detect a problem with the application getting slow, e.g. because of backend
systems not responding fast enough. In this situation we want to limit creation
of new sessions.

Example: During normal operation there are 5 static requests in work and
10 dynamic ones (that take much longer to complete). When there is a
problem with backend systems we might have 15 static ones, but more than
100 dynamic ones. So either counting or ommiting the static ones seems to
make no big difference.

You might want to take a look at the attached patch "patch_overload.txt"
for jk/native/apache1.3/mod_jk.c version 1.52. I don't have a patch for
Apache 2, but Mladen Turk has something similar for Apache 2. This patch here
places every change inside "#ifdef OVERLOAD". Also there are some
DEBUG-Log-Statements put inside "#ifdef DEBUG" which I
assume can now be done more consistently with Mladen Turks TRACE features.

Of course the "best" observable value would be the number of requests
belonging to the same webapp. So some possible enhancement would be to
count only requests with a fix URL prefix (that's not yet contained in the
patch).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message