Introduction

Configuring Jetty for highload, albeit for load testing or for production, requires that the operating system, the JVM, jetty, the application, the network and the load generation all be tuned.

Load Generation for Load Testing

The load generation machines must have their OS, JVM etc tuned just as much as the server machines.

The load generation should not be over the local network on the server machine, as this has unrealistic performance and latency as well as different packet sizes and transport characteristics.

The load generator should generate a realistic load:

A common mistake is that load generators often open relatively few connections that are kept totally busy sending as many requests as possible over each connection. This causes the measured throughput to be limited by request latency (see Lies Damned Lies and Benchmarks for an analysis of such an issue.

Another common mistake is to use a TCP/IP for a single request and to open many many short lived connections. This will often result in accept queues filling and limitations due to file descriptor and/or port starvation.

A load generator should well model the traffic profile from the normal clients of the server. For browsers, this if mostly between 2 and 6 connections that are mostly idle and that are used in sporadic bursts with read times in between. The connections are mostly long held HTTP/1.1 connections.

Load generators should be written in asynchronous programming style, so that limited threads does not limit the maximum number of users that can be simulated. If the generator is not asynchronous, then a thread pool of 2000 may only be able to simulate 500 or less users. The Jetty HttpClient is an ideal basis for building a load generator, as it is asynchronous and can be used to simulate many thousands of connections (see the Cometd Load Tester for a good example of a realistic load generator).

Operating System Tuning

Both the server machine and any load generating machines need to be tuned to support many TCP/IP connections and high throughput.

Linux

Linux does a reasonable job of self configuring TCP/IP, but there are a few limits and defaults that that are best increased. These can mostly be configured in /etc/security/limits.conf or via sysctl

TCP Buffer Sizes

These should be increased to at least 16MB for 10G paths and tune the autotuning (although buffer bloat now needs to be considered).

Queue Sizes

net.core.somaxconn controls the size of the connection listening queue. The default value of 128 and if you are running a high-volume server and connections are getting refused at a TCP level, then you want to increase this. This is a very tweakable setting in such a case. Too high and you'll get resource problems as it tries to notify a server of a large number of connections and many will remain pending, and too low and you'll get refused connections:

sysctl -w net.core.somaxconn=4096

The net.core.netdev_max_backlog controls the size of the incoming packet queue for upper-layer (java) processing. The default (2048) may be increased and other related parameters (TODO MORE EXPLANATION) adjusted with:

JVM Tuning

Jetty Tuning

Connectors

Acceptors

acceptors >=1 <= # CPUs

Low Resource Limits

Must not be configured for less than the number of expected connections.

Thread Pool

It is very important to limit the task queue of Jetty. By default, the queue is unbounded! As a result, if
under high load in excess of the processing power of the webapp, jetty will keep a lot of requests on the
queue. Even after the load has stopped, Jetty will appear to have stopped responding to new requests as it
still has lots of requests on the queue to handle.

For a high reliability system, it should reject the excess requests immediately (fail fast) by using a queue
with a bounded capability. The capability (maximum queue length) should be calculated according to the
"no-response" time tolerable. For example, if the webapp can handle 100 requests per second, and if you
can allow it one minute to recover from excessive high load, you can set the queue capability to 60*100=6000.
If it is set too low, it will reject requests too soon and can't handle normal load spike.

Configure the number of threads according to the webapp. That is, how many threads it needs
in order to achieve the best performance. Configure with mind to limiting memory usage maximum available.
Typically >50 and <500.