-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shaun,
On 7/13/2009 1:06 AM, Shaun Qualheim wrote: > Basically. We could clear things up a little bit though, just going to > https:// right away: > > client -- https:443 --> lb --> http:81 --> apache --> mod_jk --> 1 of 3 > tomcats. Yeah, this makes more sense to me. I was just wondering why you'd want to accept HTTP traffic and then proxy it through HTTPS, rather than just doing a redirect and making the client connect securely in the first place. >>> Also, why have httpd >>> forward all traffic to a load-balancer instead of just doing the >>> load-balancing itself? > > How do you mean? (Sorry, I can think of a few things that you might mean > here, but I don't want to assume.) I mean, why not just do this: client -- https:443 -> lb -> Tomcats 1-3 >>> What do your elements look like in Tomcat's server.xml? > > Here's an example of the connector. I can provide more if it would help? > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" > port="7019" minProcessors="256" maxProcessors="1024" > enableLookups="false" redirectPort="7443" > acceptCount="10" debug="0" connectionTimeout="120000" > useURIValidationHack="false" scheme="https" proxyPort="443" > > protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/> This port number says 7019, so it's either not the <Connector> you are actually using, or your setup is not how you've described it. Other than the port number, this looks fine. A few comments, though: 1. This is supposed to act like an HTTP port, so redirectPort is not useful. 2. acceptCount="10" is a little low when you're expecting to serve a maximum of 1024 simultaneous connections. Connection #1035 will be rejected by the TCP stack. Maybe this is what you want, but I would probably have a larger accept queue. 3. Your connectionTimeout is 2 minutes. That means that the server will wait up to 2 minutes for the client to make a request on a connection. That's a /loooooong/ time. You might want to consider reducing this if you expect high traffic. >>> So, does it look like you are hitting a wall (like there aren't enough >>> connections allowed) or does the application/server start to experience >>> an actual slowdown (like high CPU load, lots of paging, etc.)? >>> > > If I had to guess, I'd say the former. When we're monitoring system > resources using nmon during the load tests, everything else seems fine. I suspect you aren't looking at the right set of <Connector> elements in server.xml. You probably just have the request processors incorrectly allocated for the load you are expecting. Since everything works fine going directly to Tomcat (using HTTP, which appears to be the <Connector> you're showing above), I think you're not looking at the AJP connector (used to connect httpd -> Tomcat) which needs to be configured separately. Check the maxProcessors attribute of the /other/ <Connector>(s) defined in server.xml to see if they have appropriate values. Feel free to post /all/ your <Connector> elements to the list if you need a bit of help. Also, remove anything from server.xml that you don't need: it'll simplify your life, and the lives of your administrators. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpbPMwACgkQ9CaO5/Lv0PDGfQCeIj4NU2Aqqxfia353Ht4/Rs+w Y80AniBoUzrq+BngJpVMvjDfKXrv5AOS =fPqU -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
