[PATCH] Wokers How To Documentation
Had a bad run in with firewalls using Apache 1.3 and AJP13. Thought the following changes might help the next victim. Andrew Gilbert Index: workershowto.xml === RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.8 diff -u -r1.8 workershowto.xml --- workershowto.xml20 Sep 2002 21:35:30 - 1.8 +++ workershowto.xml15 Nov 2002 20:41:40 - -170,8 +170,7 frequently used strings as small integers. /li li -ajpv13 reuse open sockets and leaves them open for future requests (remember when you've got a Firewall between your -WebServer and Tomcat). +ajpv13 reuses open sockets and leaves them open for future requests. When you've got +a firewall between your WebServer and Tomcat you need to ensure these connections +aren't torn down during periods of inactivity. See bsocket_keepalive/b for more +information. /li li ajpv13 has special treatment for SSL information so that the container can implement -204,53 +203,36 /p p -bcachesize/b property is usefull when you're using JK in multithreaded -web servers such as Apache 2.0, IIS and Netscape. They will benefit the most by -setting this value to a higher level (such as the estimated average concurrent users for Tomcat). +bcachesize/b property is useful when you're using JK in multithreaded +web servers such as Apache 2.0, IIS and Netscape. The default value is 1. +Multithreaded web servers will benefit by setting this value to a higher level, such +as the estimated average concurrent users for Tomcat. With forking model web servers +you probably want to use the default. /p p -bcache_timeout/b property should be used with bcachesize/b to specify how to time JK should keep -an open socket in cache before closing it. This property should be used to reduce the number of threads -on the Tomcat WebServer. +bcache_timeout/b property should be used with bcachesize/b to specify how +long JK should keep inactive connections in the cache before cleaning them up and +closing them. Note that this property will have no affect with the default cachesize +of 1. /p p -You should know that under heavy load some WebServers, for example Apache's create many childs/threads -to handle the load and they destroy the childs/threads only when the load decrease. +In a multithreaded web server scenario an AJP13 worker will use the cache to manage +connection load to Tomcat. As load increases the web server will create threads to +handle the load, and the AJP13 worker will create, cache and reuse connections to +Tomcat as required, up to bcachesize/b. As load decreases the web server is +responsible for reaping extra threads, and the worker will clean out connections to +Tomcat per the bcache_timeout/b property. Note this clean up occurs only when new +activity resumes following idle time. There is no reaper thread. /p -p -Each child could open an ajp13 connection if it have to forward a request to Tomcat, creating -a new ajp13 thread on Tomcat side. +p +Tomcat creates a new thread to handle each connection. By recovering unused +connections from the cache, threads on Tomcat that are servicing idle connections +will be recovered as well. /p -p -The problem is that after an ajp13 connection is created, the child won't drop it -until killed. And since the webserver will keep its childs/threads running -to handle high-load, even it the child/thread handle only static contents, you could -finish having many unused ajp13 threads on the Tomcat side. +p +In a forking model scenario, the web server will create new processes to handle load. +Each process will have it's own cache. Each cache will probably not extend beyond one +connection. The benefit of the cache in this scenario is marginal. Connections that +exist to Tomcat will be cleaned only when inactive child processes are cleaned by the +web server. /p p -bsocket_keepalive/b property should be used when you have a firewall between your webserver -and the Tomcat engine, who tend to drop inactive connections. This flag will told Operating System -to send codeKEEP_ALIVE/code message on inactive connections (interval depend on global OS settings, -generally 120mn), and sus prevent the firewall to cut the connection. +bsocket_keepalive/b property should be used when you have a firewall that drops +inactive connections between your webserver and Tomcat. This property will cause the +keep alive flag to be set on socket connections to Tomcat. The operating system will +then send codeKEEP_ALIVE/code packets on inactive connections. The keep alive +timeout is often a global OS setting, usually of 120 minutes. The keep alive packets +will prevent the firewall from cutting the connection because of no activity. Be sure +to adjust either the firewall or operating system so that keep alives happen inside +the window of firewall timeouts. /p p
[PATCH] Which access time determines cache cleanup?
Not sure about this, but would seem to make more sense that an endpoint gets cleaned
out of the cache based on it's own last access time, not the last access time of the
endpoint that has been taken out for use. Or is this intentional?
Andrew Gilbert
Index: jk_ajp_common.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.32
diff -u -r1.32 jk_ajp_common.c
--- jk_ajp_common.c 30 Oct 2002 22:12:20 - 1.32
+++ jk_ajp_common.c 15 Nov 2002 20:57:33 -
-1420,7 +1420,7
if (aw-cache_timeout) {
for ( ; i aw-ep_cache_sz ; i++) {
if (aw-ep_cache[i]) {
-unsigned elapsed = (unsigned)(now - ae-last_access);
+unsigned elapsed = (unsigned)(now -
+aw-ep_cache[i]-last_access);
if (elapsed aw-cache_timeout) {
jk_log(l, JK_LOG_DEBUG,
In jk_endpoint_t::ajp_get_endpoint, \
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
Thanks.
I missed the obvious in the double array copy. Still, by doubling the buffer
size each time instead of incrementally increasing we are getting double the
speed with our degenerate test case.
1. Original - 22 seconds
2. As patched here - 13 seconds
3. With doubling of buffer as well - 6 seconds
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 03, 2001 10:26 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime
BodyContentImpl.java
marcsaeg01/03/03 19:26:22
Modified:src/share/org/apache/jasper/runtime Tag: tomcat_32
BodyContentImpl.java
Log:
BodyContentImpl.java
Revision ChangesPath
No revision
No revision
1.6.6.1 +6 -8
jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
Index: BodyContentImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl
.java,v
retrieving revision 1.6
retrieving revision 1.6.6.1
diff -u -r1.6 -r1.6.6.1
--- BodyContentImpl.java 1999/11/13 00:32:51 1.6
+++ BodyContentImpl.java 2001/03/04 03:26:21 1.6.6.1
@@ -88,7 +88,7 @@
super(writer);
cb = new char[bufferSize];
nextChar = 0;
-}
+ }
/**
* Write a single character.
@@ -107,19 +107,19 @@
//Need to re-allocate the buffer since it is to be
//unbounded according to the updated spec..
-char[] tmp = new char [bufferSize];
- System.arraycopy(cb, 0, tmp, 0, cb.length);
+char[] tmp = null;
//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
if (len = Constants.DEFAULT_BUFFER_SIZE) {
- cb = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
+ tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
bufferSize += Constants.DEFAULT_BUFFER_SIZE;
} else {
- cb = new char [bufferSize + len];
+ tmp = new char [bufferSize + len];
bufferSize += len;
}
- System.arraycopy(tmp, 0, cb, 0, tmp.length);
+ System.arraycopy(cb, 0, tmp, 0, cb.length);
+ cb = tmp;
tmp = null;
}
@@ -499,8 +499,6 @@
public void clear() throws IOException {
synchronized (lock) {
-cb = new char [Constants.DEFAULT_BUFFER_SIZE];
- bufferSize = Constants.DEFAULT_BUFFER_SIZE;
nextChar = 0;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Tomcat 3.2.1 - bufferSize in BodyContentImpl
We made the following change to reAllocBuff() in
org.apache.jasper.runtime.BodyContentImpl with some success. Curious if this
is of use to others. There was already a note about using a multiple of
DEFAULT_BUFFER_SIZE. This takes the notion one step further, doubling size
upon each request. Made a tremendous impact on performance for a page where
a body tag was generating a lot of output. This function, and the array
copy, were taking a big chunk of CPU to deal with the degenerate situation.
Another option would be to get the bufferSize from JspWriter, as this would
allow the buffer page directive to affect BodyContent as well. Felt the
doubling was more effective and simple.
Thanks,
Andrew
113,117c113,114
//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
if (len = Constants.DEFAULT_BUFFER_SIZE) {
cb = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
bufferSize += Constants.DEFAULT_BUFFER_SIZE;
---
if (len = bufferSize) {
bufferSize = bufferSize * 2;
119d115
cb = new char [bufferSize + len];
121a118,119
cb = new char [bufferSize];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
