views:

2258

answers:

3

I am maintaining a website with currently about 800 concurrent users. The business plan says that this number will be 10x higher in one year.

This is my current configuration:

<Connector port="8080" address="${jboss.bind.address}"
  maxThreads="500" maxHttpHeaderSize="8192"
  emptySessionPath="true" protocol="HTTP/1.1"
  enableLookups="false" redirectPort="8443" acceptCount="100"
  connectionTimeout="20000" disableUploadTimeout="true" />

<Connector port="8443" address="${jboss.bind.address}"
  protocol="HTTP/1.1" SSLEnabled="true"
  maxThreads="500" minSpareThreads="5" maxSpareThreads="25"
    scheme="https" secure="true" clientAuth="false"
    keystoreFile="${jboss.server.home.dir}/conf/ks.p12"
    keystoreType="PKCS12" connectionTimeout="20000"
    keystorePass="pass" sslProtocol="TLS" acceptCount="100" />

The average used thread count is about 400 (for each http/https). But peaks really use 500 threads. I think I will get into trouble when I get 10x users :-)

  • How can I tune this?
  • Should I disable http keep alive? How can I configure keep-alive timeout?
  • What values are good for acceptCount / maxThreads?
+1  A: 

You can tune this using JMeter. I think much depends on your specific hardware setup. A possible way to scale your site is to add machines. Check out the Velocity Conference and the High Scalability website.

Yuval F
Yes I know that I can scale with more machines. But first I want to get the most out of the hardware that is already in use.
Marcel
+1  A: 

I think that putting tomcat in Apache Http server is much more robust and faster approach. here are the pros & cons taken from http://wiki.apache.org/tomcat/FAQ/Connectors

Why should I integrate Apache with Tomcat? (or not)

There are many reasons to integrate Tomcat with Apache. And there are reasons why it should not be done too. Needless to say, everyone will disagree with the opinions here. With the performance of Tomcat 5 and 6, performance reasons become harder to justify. So here are the issues to discuss in integrating vs not.

  • Clustering. By using Apache as a front end you can let Apache act as a front door to your content to multiple Tomcat instances. If one of your Tomcats fails, Apache ignores it and your Sysadmin can sleep through the night. This point could be ignored if you use a hardware loadbalancer and Tomcat's clustering capabilities.
  • Clustering/Security. You can also use Apache as a front door to different Tomcats for different URL namespaces (/app1/, /app2/, /app3/, or virtual hosts). The Tomcats can then be each in a protected area and from a security point of view, you only need to worry about the Apache server. Essentially, Apache becomes a smart proxy server.
  • Security. This topic can sway one either way. Java has the security manager while Apache has a larger mindshare and more tricks with respect to security. I won't go into this in more detail, but let Google be your friend. Depending on your scenario, one might be better than the other. But also keep in mind, if you run Apache with Tomcat - you have two systems to defend, not one.
  • Add-ons. Adding on CGI, perl, PHP is very natural to Apache. Its slower and more of a kludge for Tomcat. Apache also has hundreds of modules that can be plugged in at will. Tomcat can have this ability, but the code hasn't been written yet.
  • Decorators! With Apache in front of Tomcat, you can perform any number of decorators that Tomcat doesn't support or doesn't have the immediate code support. For example, mod_headers, mod_rewrite, and mod_alias could be written for Tomcat, but why reinvent the wheel when Apache has done it so well?
  • Speed. Apache is faster at serving static content than Tomcat. But unless you have a high traffic site, this point is useless. But in some scenarios, tomcat can be faster than apache. So benchmark YOUR site.
  • Socket handling/system stability. Apache has better socket handling with respect to error conditions than Tomcat. The main reason is Tomcat must perform all its socket handling via the JVM which needs to be cross platform. The problem is socket optimization is a platform specific ordeal. Most of the time the java code is fine, but when you are also bombarded with dropped connections, invalid packets, invalid requests from invalid IP's, Apache does a better job at dropping these error conditions than JVM based program. (YMMV)
Yonatan Maman
Very nice marketing for apache. But I am bonded to tomcat... company policy :-)
Marcel
Company policy denies solutions to obvious problems? That means you are not even allowed to benchmark apache as frontend, serving static content? Wow.
Olaf
I hope you will not categorize it as a marketing (I dont have any stocks invested on Apache), I do think that this type of a deployment (Apache as a frontend) is a common configuration and considered as a best practice
Yonatan Maman
We have 99% dynamic contents. "With the performance of Tomcat 5 and 6, performance reasons become harder to justify." We want to stay with tomcat... I just want to fine tune the configs...
Marcel
A: 

I'd also look into tuning the underlying JVM, not just tomcat- check out this question for some good tips, particularly around garbage collection and memory allocation. In my experience, JVM tuning is much more effective than tuning Tomcat's internals.

Tim Howland
Thanks for your answer. But this is no problem. GC is very optimized.
Marcel