private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
There are many ways to optimize Jetty, which vary depending on the situation. Are you trying to optimize for number of requests within a given amount of time? Are you trying to optimize the serving of static content? Do you have a large bit of hardware that you want to give entirely over to Jetty to use to its heart's delight? Here are a few of the many different ways to optimize Jetty.
Tuning the JVM garbage collection (GC) can greatly improve Jetty performance. Specifically, you can avoid pauses while the system performs full garbage collections. Optimal tuning of the GC depends on the behaviour of the application and requires detailed analysis, however there are general recommendations.
See official Java 8 Garbage Collection documentation for further assistance.
These options are general to the Oracle JVM, and work in a Java 8 installation. They provide good information about how your JVM is running; based on that initial information, you can then tune more finely.
The most important thing you can do for yourself when worrying about GC is to capture the GC activity so that you can analyze what is happening and how often it happens.
-verbose:gc -Xloggc:/path/to/myjettybase/logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+PrintCommandLineFlags -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy
There are not many recommended options for GC that can apply to nearly all users.
However, the most obvious one is to disable explicit GC (this is performed regularly by RMI and can introduce an abnormal amount of GC pauses)
Before you apply any other GC tuning options, monitor your GC logs to see if tuning the CMS makes sense for your environment.
A common setup for those just starting out with GC tuning is included below for reference reasons.
This example configuration below could have a negative effect on your application performance, so continued monitoring of your GC log before and after is highly recommended to know if the configuration was beneficial or not.
-XX:MaxGCPauseMillis=250 -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads=2 -XX:+CMSClassUnloadingEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80