Put at start of "bin/startup.sh"
export CATALINA_OPTS="-Xmx`cat /proc/meminfo | grep MemTotal | awk '{ print $2*0.75 } '`k"
..to use 75% of your total system memory for JVM.
Add to /bin/tomcat.sh or whatev's
Monday, October 18, 2010
Tuesday, October 12, 2010
SSL performance of Tomcat and Apache Commons HTTP
Using latest Tomcat 6 on Java 1.6 on Centos.
1. Tomcat JSSE (standard) SSL option is much slower than the Apache Portable Runtime (APR) libaries.
SSL performance (using CURL to upload large binaries via HTTPS to localhost on a multicore box) was getting
5.3MBytes/sec using Tomcat default SSL (100% Java on one CPU), and getting >30MBytes/sec using Tomcat with APR (basically OpenSSL) and lower CPU usage.
Conclusion: Well worth the hassle installing APR for incoming (and probably outgoing) e.g. 5x faster SSL traffic, lower less Java CPU.
2. Beware using standard libraries to upload to Rackspace Files and other HTTPS-accessed key:value stores. Using Apache Commons HTTP Uploader tops out at about 2mbytes/sec on one machine compared to 5mbytes/sec using CURL or WGET from command line. This was very repeatable.
3. Speed writing from Rackspace Cloud Server to Rackspace Files using CURL (i.e. running flat-out)
(See that the different CLoud Server options have different bandwidth clamps as well as significantly faster CPU)
Uploading a 176MB object to Rackspace Files, using CURL from command line to do a PUT
"512MB machine" : 5.02MBytes/sec (very reliably - this is clamped by network)
"1GB machine" : 7.65MBytes/sec (again network bound, more expensive server)
"16GB machine" : 15MBytes/sec
CPU in these cases (for Curl) is <10% typically.
In all cases running two threads (these are multicore machines) gets exactly half the performance, indicating networtj throttle.
HOWEVER if you don't use OpenSSL for your HTTPS....
Using Apache HTTP Uploader (and most likely any 'pure'-Java SSL options that are using JSSE) only gets
"512MB machine" : 2.1MBytes/sec (this is 100% CPU on that java thread)
Conclusion:
...creating outbound HTTPS connections using Java SSL gets CPU-bound really quickly - watch for this when using JSSE-based Java SSL clients.
1. Tomcat JSSE (standard) SSL option is much slower than the Apache Portable Runtime (APR) libaries.
SSL performance (using CURL to upload large binaries via HTTPS to localhost on a multicore box) was getting
5.3MBytes/sec using Tomcat default SSL (100% Java on one CPU), and getting >30MBytes/sec using Tomcat with APR (basically OpenSSL) and lower CPU usage.
Conclusion: Well worth the hassle installing APR for incoming (and probably outgoing) e.g. 5x faster SSL traffic, lower less Java CPU.
2. Beware using standard libraries to upload to Rackspace Files and other HTTPS-accessed key:value stores. Using Apache Commons HTTP Uploader tops out at about 2mbytes/sec on one machine compared to 5mbytes/sec using CURL or WGET from command line. This was very repeatable.
3. Speed writing from Rackspace Cloud Server to Rackspace Files using CURL (i.e. running flat-out)
(See that the different CLoud Server options have different bandwidth clamps as well as significantly faster CPU)
Uploading a 176MB object to Rackspace Files, using CURL from command line to do a PUT
"512MB machine" : 5.02MBytes/sec (very reliably - this is clamped by network)
"1GB machine" : 7.65MBytes/sec (again network bound, more expensive server)
"16GB machine" : 15MBytes/sec
CPU in these cases (for Curl) is <10% typically.
In all cases running two threads (these are multicore machines) gets exactly half the performance, indicating networtj throttle.
HOWEVER if you don't use OpenSSL for your HTTPS....
Using Apache HTTP Uploader (and most likely any 'pure'-Java SSL options that are using JSSE) only gets
"512MB machine" : 2.1MBytes/sec (this is 100% CPU on that java thread)
Conclusion:
...creating outbound HTTPS connections using Java SSL gets CPU-bound really quickly - watch for this when using JSSE-based Java SSL clients.
Subscribe to:
Posts (Atom)