TOMCAT TUNING

Three factors negatively impact Tomcat’s performance more than any others – network delays, remote client latency, and application architecture.

Two of these factors – network delays and remote client latency – are for the most part unavoidable, although using a web server in front of Tomcat to serve static content will free up more power for dynamic content.

Remote client latency can be mitigated by compressing content with Apache mod_zip or Tomcat’s compression filter.

ulimit-n 8192

logging

logging is ok, but it will:

• Catch-all logger goes to stdout and file
• No overflow protection
• Synchronized logging

In linux turn off console handler.so we can:

 Remove logging to stdout-no rotation.modify logging.properties, and remove ConsoleHandler as follows: . Handlers = 1catalina.org.apache.juli.FileHandler 

Our tuning options

• Threads

  MaxThread – Max number of concurrent requests, can be set to 400, if the cpu load is very low added value, if the load is high, decrease it.

• Keep alive requests

  HTTP KeepAlive is a good thing, but Wasted server resources, thread idle while others waiting to be serviced. Https handshake is very expensive, you can use the keepalive MaxKeepAliveRequests – max number of requests to serve before closing, can not be set too large, too large thread the idle too much, but can not provide the service in highly concurrent environments, to close off KeepAlive is set to 0. spring tc server recommended setting is 15.

• TCP Backlog (acceptCount)

  Represents nr of additional connections the OS should accept on your behalf, Useful when Tomcat can’t accept connections fast enough, Typical ranges 50-300. Peak period declined more servers to increase this value.

• connectionTimeout

  His following meanings:

  • Values from 2000-60000
  • Represents the SO_TIMEOUT value
  • Essentially, max time between TCP packets during a blocking read or write
  • Critical to a stable system
  • Also used for keep alive timeout ConnectionTimeOut – max time to keep thread open default 20s this value is too high for a web server in terms of reasonable setting, according to the application scenario. The recommended value is 3000, Increase if Working with slow clients (dial up) or Using a layer 7 load balancer with connection limit / pool and keep alive on.

Different connectors

• BIO-Blocking Java connector, default
• The APR-Uses native C code for IO Overall very good, especially ssl, try using this model
• NIO-Non blocking Java connectors

Dynamic content

No way in tomcat level cache, can use jsp cache to cache content like blocking mode of the Tomcat has to deliver it, Worker thread is not the released The until all content has been delivered, Changing the connector wont change behavior

Static content

• The tomcat providing Size based cache, default 10mb, for BIO-Tomcat has to deliver it blocking mode
• NIO / APR, Tomcat can use SEND_FILE, Release worker thread, deliver the content using a background thread when the client is ready to receive, Increases concurrency

Do not use the AJP protocol

JVM TUNING

Key parameters for JVM tuning

• Memory

  Total heap: -Xms/-Xmx

  Used to define size of Java heap Aim to set as low as possible Setting too high can cause wasted memory and long GC cycles 

• Control of the new generation:-XX: Xmn

  Size eden + the New gen displayed in the survivor space. With The jmap-heap different. Increasing the young generation will reduce the size of the old generation. Value impact on system performance, Sun official recommended configuration for the entire heap of 3/8, do not use jdk1.4 previous parameter XX: XX NewSize: NewRatio , according to the case of the test, 3/8 is still relatively large, set at about 30% more appropriate. Setting too high or too low leads to inefficient GC. Too big, minor gc will stop the world, too small, too often.

• Garbage collection

   -XX: MaxGCPauseMillis This parameter can not do not use very dangerous set too short to gc spend a lot of effort to reach their goals, resulting in decreased throughput. -XX: + UseConcMarkSweepGC -XX: + CMSIncrementalMode -XX: + CMSIncrementalPacing -XX: CMSIncrementalDutyCycleMin = 0 -XX: CMSIncrementalDutyCycle = 10 -XX: + UseParNewGC -XX: + CMSPermGenSweepingEnabled 

  Note that last this CMSPermGenSweepingEnabled, in jdk1.6 after cms collector can be achieve permgen recycling, especially for groovy such dynamically generated class and the program loaded.

gc log:

-Verbosegc-XX: + PrintGCTimeStamps-XX: + PrintGCDetails-Xloggc: gc.log