yes. my configuration is just a suggestion. if you just need to fix the problem quickly, maybe you need to try some solutions. But the main idea to solve this problem is you need to do some tests to find out where the bottleneck is.
I did a lots of tests, because my server chain is too long httpd load balancer -> tomcat -> activeMQ -> db. now my problem of load balancer is solved (in fact I just need the default configuration). My Problem is caused by my program. the servlet on tomcat process the request for a long time (1s more), and not very stable. I think you'd better make sure your program is ok. You can test just a static html page, and find out whether the tomcat server will down. there are something you need to know: (these results are passed by my tests) the httpd + mod_jk load balancer is powerful, my test case shows that it can hold more than 6000 request per second!! and tomcat is also powerful 500 request per second is ok. On Wed, Apr 15, 2009 at 4:57 PM, André Warnier <a...@ice-sa.com> wrote: > WenDong Zhang wrote: > >> I've the same problem too, and I found that if the tomcat response time is >> long, you need to set connection_pool in your workers.properties. >> >> Ok, let me be more explicit. > What you suggest above may work, /if/ the underlying reason for the problem > meets certain criteria. But is is not a generic solution to what the OP > indicates. We have no idea if Tomcat's response is slow or not, or if it is > even requests to Tomcat that are involved. (The OP indicated that Tomcat > itself was still fine, it was Apache which was not responding anymore; I > don't know exactly what he meant by "Tomcat is still fine", but let's take > this at face value). > > If you start from the beginning (and simplifying a bit): > - the browser sends a HTTP request to Apache > - if the network is OK, and the host is not overloaded, Apache receives > this request. > - if Apache has a child or thread free to handle this request, it passes > the request to it > - if mod_jk in the child/thread determines that this request should be > handled by Tomcat, it opens a connection to Tomcat to pass the request (or > it re-uses an existing connection if it still has one, for efficiency). (If > the request is not for Tomcat, mod_jk declines it and it is handled locally > by something in Apache.) > - if the Connector at the Tomcat side is not overloaded, it accepts the > request, and if it still has threads to spare, it starts a thread to handle > the request > - the thread takes a while (short/long) to process the request and generate > a response > - during that time, mod_jk waits for the response > - when the response starts arriving back from Tomcat, mod_jk starts writing > it back to the pipe that is ultimately connected to the client browser. > - when the response has been entirely produced by the Tomcat thread, it is > done and can rejoin the pool of available threads > - similarly, when mod_jk has received the entire response, it can return > this connection (to Tomcat) to the pool > - similarly, the Apache thread/child that was processing this request can > go back to the available pool > - etc... > > Now at any time during the above, a number of things can happen : > - the user may get impatient because it takes a long time for Tomcat to > produce the response. So he clicks on the cancel or "refresh" icon, or > clicks on another link. So when mod_jk receives a piece of the response > from Tomcat and tries to forward it to the client, it finds a closed socket, > and it prints a warning. > - the request may not be handled by Tomcat, but instead by a buggy > application in Apache itself, which gradually paralises Apache. > - between the browser and the server, there is some equipment that decides > that nothing has happened on this connection for a long time, and closes it > down. The browser gets an error, and so does mod_jk when it tries to write > to the client. > - mod_jk tries to connect to Tomcat, and gets refused because the Tomcat > connector has no more "queued-up connection slots" available on that port. > - Tomcat accepts the connection and puts it in the queued-up connections, > waiting for an available thread to process the request. > But other previous requests take a long time to process, so after 2-3 > minutes, the browser decides that the server is not responding, closes the > connection and displays an error page to the user. > And mod_jk finds a closed client socket when ultimately it wants to send > the Tomcat response to the client. > - there are genuine network problems between the client and the server, > causing connections to drop > - the sysadmin has played around with the setup of Apache and mod_jk and > the JVM and Tomcat to the point that Apache accepts 10,000 requests per > second, but the backend Tomcat can only handle 100 at any one time. > - there is a bug in a webapp that causes it to leak resources over time, > gradually slowing down Tomcat > > And so on... > The point is, there are many situations that are possible, and there is not > one magic fix for them all. > You have to know what exactly is the problem (or at least have a clue), > before you start modifying parameters left and right blindly, and possibly > making the situation even worse. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Best Regards! Wen Dong
