views:

604

answers:

1

Hello, I am doing stress tests with JMeter on web application (built with Spring, Struts2 REST, uses PostgreSQL).

I am simulating typical user's scenario with my app - 4 GET, 3 INSERT, 20 UPDATE calls.

Server specs: 4core Intel Xeon X5365 3GHz 8GB RAM single 320GB SATA disk OS: Ubuntu 8.10 32bit DB: Postgresql 8.4 Tomcat 6.0.18 Java 1.6.0_14

My results show me that server would handle around 130 concurrent transactions. Is this number possible? Are there any results online to compare with mine?

+2  A: 

The bottleneck will be in your database so this is very hard to compare without knowing your database performance.

We have a similar machine (except with 16GB RAM, running Tomcat 5.5). In peak load, it can easily serve 256 simultaneous connections. We are debating to change the maxThreads to 512.

Some tuning tips,

  1. If you run Apache as front-end, use mod_jk. Its performance is much better than mod_proxy.
  2. If you serve HTTP directly or use mod_proxy, use the NIO connector in Tomcat 6.
  3. Make sure your thread pool (maxThreads) is large enough, default is only 200.
  4. Make Tomcat state-less. Especially, don't use HttpSession. The state may cause memory leak in the app and degrade the performance gradually. Push all your state to database or client (cookies).
  5. Do use Database pooling (DBCP). We have MySQL, the JDBC driver is very chatty.
  6. If you run one instance of JMeter, it may become the bottleneck. Run multiple slaves from different networks to simulate real production load.
ZZ Coder
Nice list, but instead of `commons-dbcp`, better use `tomcat-jdbc`. DBCP is namely singlethreaded. More info: http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html
BalusC
DBCP has been around for a long time, its weakness is well-known. Anyone using it already know how to deal with it. We get great performance with it. The Tomcat Pool is so new. I don't want jump on it right now.
ZZ Coder
Really great answer. Tomorrow I will try everything and get back.
Trick
Working with database slows down approximately by factor 3!!! 10ms ~ 30ms... I thought that it would be less. But with your help and other things we are now on 300 concurrent connections without errors (timeouts).
Trick