Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Jetty/Howto/High Load

< Jetty‎ | Howto
Revision as of 20:19, 23 February 2011 by Gregw.webtide.com (Talk | contribs) (New page: {{Jetty Howto | introduction = Configuring Jetty for highload, albeit for load testing or for production, requires that the operating system, the JVM, jetty, the application, the network a...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)



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.

Operating System Tuning

Network Tuning

Jetty Tuning

Connectors

Acceptors

Low Resource Limits

Thread Pool

Back to the top