"Antonio Fiol Bonn�n" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Bill Barker wrote: > > >In theory, I'd go with Kwok's recommendation: one Apache with it's own > >load-balancer, and 3 Tomcats instead of 3 Apaches. However, in the > >real-world, this would require you to upgrade to Apache 2.0.x with the > >'worker' MPM. > > > > We cannot repurpose machines. Three web servers (a fourth one is in the > way, don't ask why) are a need for other projects, as Apache servers are > shared. And technically, I don't think it is viable either (see previous > post). > > However, I am worried about what you say about Apache 2.0.x and the > 'worker' MPM. Could you please tell me about the real-world > inconveniences of having 3/4 Apache 1.3.X with 2/3 tomcats behind? >
The mod_jk loadbalancer doesn't work well with pre-fork (including Apache 1.3.x on *nix systems). Since your not using the mod_jk loadbalancer, it shouldn't matter if you are using 1.3.x or 2.0.x. > > >Yes, for your current config, you need to have your maxProcessors somewhere > >near 600 to handle peak load. For part two, go to each of your Apache > >machines and run: > > $ ps -ef | grep httpd | wc -l > > > > Done that. Very varying, depending on time of day. But we set MaxClients > to 200 knowing what we were doing. We used to have 100 and it was not > enough. Raised to 150 and still not enough. It was during a peak period, > but I don't think we should lower it back. > > > > >Add the numbers together, and subtract three (one for each of the Apache > >'controller' processes). If the system has been running for awhile, this > >should be about the same as the number of connections to your Tomcat server > >on 8009, since mod_jk holds the connection open (by default) for the > >lifetime of the Apache child. > > > The problem is that the connection is kept open even if unused, isn't it? > > I mean: If I do not connect to my web-app, does it start the connections? It will (by default) open the connection the first time that an Apache child gets a request for your web-app. After that the connection stays open for the lifetime of the Apache child. You can change the default by setting the connectionTimeout attribute on the Connector to a positive value (in milliseconds): e.g. connectionTime="60000". This will cause the Tomcat thread to drop the connection to Apache if it doesn't recieve another request in the specified time (e.g. in the example 1 minute), and terminate. Generally, this hurts performance. However on one of my Linux 7.x boxes it improved the stability by reducing the average total thread count in Tomcat. > > > The threads that are waiting for Apache to > >talk to them are blocked pending input, so aren't affecting Tomcat's > >performance in any way. > > > Except maybe memory requirement?? > > > >Since you are using 4.1.9, I'm assuming that you are using the AjpConnector > >(instead of the newer CoyoteConnector). > > > I think it is CoyoteConnector, but I'd have to check to be sure. > > We'll be moving to 4.1.26 as soon as we have time to test our app on it. > Stuck on 4.1.9 because of client cert auth problem. > > > > With the AjpConnector, you can set the attribute > >'connectionTimeout=xx-ms"' to have Tomcat drop the connection to Apache > >after xx milliseconds have gone by without traffic. > > > Does that apply to CoyoteConnector? Is it really useful? > > >For tuning, I like OptimizeIt (but it costs). > > > It helped me once upon a time. But I'm in a different company now. > > > I'm sure that other people > >will offer there opinions. > > > Yes, I heard of JProbe. Never tested. Any insights? How is it compared > to (3 years ago) OptimizeIt? > > > Thank you very much for your answer, Bill. I think it was really useful. > > > Antonio Fiol >
smime.p7s
Description: S/MIME cryptographic signature
