Optimizing Jetty

Jetty has a few features that have been deprecated or that are particularly resource hungry. Before starting optimizing the more conventional attributes it is worthwhile to make sure that these features are turned off or minimally configured.

Request Log Buffering

The Jetty request log mechanism has the ability to buffer its output in memory before writing this to a file, which was intended to reduce synchronization load on the server. Unfortunately analysis of actual performance shows that the a server with buffering turned on has around 5% maximum throughput. Prior to Jetty release 4.2.9 log buffering was turned on by default. This should be turned off:

  ...
  
    
      /logs/yyyy_mm_dd.request.log
      90
      true
      false
      false
      GMT
    
  
  ...

Statistics

The Jetty server supports statistic collection at the server and at the context level. While stats collection itself does not involve significant work load, it does require synchronization in order to correctly count some statistics. On a multi CPU machine, this extra synchronization could significantly affect the performance of the server, thus statistics should be turned off while optimizing the server. Note that this is somewhat counter productive, as the statistics are very useful for measuring the results of optimization. Thus the recommended use of the server statistics is to measure the profile of real load being handled by the server. This profile can then be used in generating test load, hopefully from a test client which itself can generate statistics which can be used to evaluate optimizations.

NIO SocketChannelListener

Jetty releases from release 4.0.0 to 4.2.9 contained the SocketChannelListener implementation of the HttpListener interface. This implementation used the features of the java 1.4 NIO library to use non-blocking sockets for idle connections. The intent was to avoid allocating a java thread to idle connections. Unfortunately, due to the nature of the servlet API, the sockets had to be returned to blocking mode before control was passed to a servlet. The resulting constant changing of the NIO select sets proved to consume significantly more system resources than was saved by reducing the required number of threads. The SocketChannelListener has been deprecated since 4.2.10 and should not be used for any release unless for experimental purposes.

Max Read Time

The Jetty HTTP Listeners in versions prior to 4.1.1 had a parameter called maxReadTime, which was used to limit the time a request handler would wait for request content (e.g. on a form POST). This parameter, like maxIdleTime, was used to set the SO timeout value on the underlying connection socket. Unfortunately, if the maxReadTime value was different to the maxIdleTime value, then the SO timeout value was changed twice for every request. This proved to cause a significant reduction of throughput of the server, in the order of 10%. Thus for Jetty versions prior to 4.1.1 it is important to set the maxIdleTime and maxReadTime parameters to the same value:

  
    
      
        808025
        255
        60000
        60000
      
    
  
  ...

For Jetty versions 4.1.1 or later, maxReadTime should not be set as it is ignored and produces a warning.