Jetty 9.3.6 and Oracle Java 8 installed, JAVAHOME pointing to the Java 8 installation, Jetty placed in /opt/jetty. Login as root or use all commands in sudo context. Let's begin in the /opt/jetty/lib folder: cd /opt/jetty/lib. Create an obfuscated password. Jetty is a lightweight Web server written in Java. Market Share by Top Websites 1 Apache is leading in Top 10K Sites, Top 100K Sites, Top 1M Sites and The Entire Web. 2 In terms of market share, Jetty is clearly lagging behind, losing to Apache in all segments.
DGLux5 Server is an enterprise-ready, fully-integrated DGLux5 web server packaged with Apache Tomcat 7.0.55. Security and web hosting is handled by Tomcat, which makes it easy to customize for your specific needs and preferred user authentication mechanism (including LDAP). 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).
- Navigation
- Main Page
- Community portal
- Current events
- Recent changes
- Random page
- Help
Jetty Server Download
- Toolbox
- Page information
- Permanent link
- Printable version
- Special pages
- Related changes
- What links here
- 3Operating System Tuning
- 3.1Linux
- 6Jetty Tuning
- 6.1Connectors
Introduction
Jetty 7 and Jetty 8 are now EOL (End of Life)
THIS IS NOT THE DOCUMENTATION YOU ARE LOOKING FOR!!!!!
All development and stable releases are being performed with Jetty 9 and Jetty 10.
This wiki is now officially out of date and all content has been moved to the Jetty Documentation Hub
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:
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:
Ports
If many outgoing connections are made (eg on load generators), then the operating system may run low on ports. Thus it is best to increase the port range used and allow reuse of sockets in TIME_WAIT:
File Descriptors
Busy servers and load generators may run out of file descriptors as the system defaults are normally low. These can be increased for a specific user in /etc/security/limits.conf:
Congestion Control
Linux supports pluggable congestion control algorithms. To get a list of congestion control algorithms that are available in your kernel run:
If cubic and/or htcp are not listed then you will need to research the control algorithms for your kernel. You can try setting the control to cubic with:
Mac OS
Windows
Seriously???
Network Tuning
- Intermediaries such as nginx can use non persistent HTTP/1.0 connection. Make sure that persistent HTTP/1.1 connections are used.
JVM Tuning
- Tune the Garbage Collection
- Allocate sufficient memory
- Use the -server option
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 queuewith 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.
Below is a sample configuration:
Configure the number of threads according to the webapp. That is, how many threads it needsin order to achieve the best performance. Configure with mind to limiting memory usage maximum available.Typically >50 and <500.
BBjServices integrates a Web Server based on the Eclipse project's server, Jetty. Jetty serves applications in production all over the world and is an industrial-strength solution. General server-wide configuration happens in Enterprise Manager. This type of configuration covers the server ports, hostname, and SSL configuration. BBj makes use of Jetty in a few different ways. The specific services are configured in other parts of Enterprise Manager, or within a BBj program. BUI, Web Start, Web Services, and the demos are all handled within Enterprise Manager.
By default, Jetty serves http requests on port 8888 and https requests on port 8443. To customize the ports from the Web Configuration:
ExpandBBjServices.
Double-clickServersin the BBj EM Navigator and the settings tab will open to the right.
Expand theWeb settingsto see the configurations.
Jetty, by default, logs to the request.log file in the logs directory. Each request to the Web Server generates a line in the logfile. Each line includes the IP address of the remote host, the time and date, and finally the http request. Logged information is not currently configurable.
Jetty serves any files in the htdocs directory under the /files path prefix. For example, the file BBj.png resides in the htdocs/images subdirectory of BBj home. To view that image directly in a web browser, navigate to localhost:8888/files/images/BBj.png (all paths are case sensitive).
By default, BUI applications are served under the /apps path prefix, but this path prefix can be altered under the Context Configuration . When the application named 'test' is published in Enterprise Manager, the application is reachable through localhost:8888/apps/test. BUI applications may be published programmatically as well.
By default, Web start applications are served under the /jnlp path prefix, but this path prefix can be altered under the Context Configuration. Applications are configured in the JNLP section of Enterprise Manager. Signed jars are also available from the /jnlp prefix. Any jar placed in the lib directory will be copied to a cache directory, compressed, and signed. Download BBjThinClient.jar directly from localhost:8888/jnlp/BBjThinClient.jar or the packed version from localhost:8888/jnlp/BBjThinClient.jar.pack.gz.
By default, Web Services are served from the /webservice path prefix, but this path prefix can be altered under the Context Configuration . Web Services are configured in the Web Service section of Enterprise Manager. Accessing a Web Service generally requires creating a specialized client to use the service. However, the WSDL (Web Service Description Language) file is available directly. The BUS Web Service is installed by default in BBj, accessible from localhost:8888/webservice/BUS?wsdl.
By default, BBjServlets are served from the /servlet path prefix but this path prefix can be altered under the Context Configurationand BBjServlets are deployed programmatically. See BBj Servlet Overview.
THIS IS NOT THE DOCUMENTATION YOU ARE LOOKING FOR!!!!!
All development and stable releases are being performed with Jetty 9 and Jetty 10.
This wiki is now officially out of date and all content has been moved to the Jetty Documentation Hub
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:
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:
Ports
If many outgoing connections are made (eg on load generators), then the operating system may run low on ports. Thus it is best to increase the port range used and allow reuse of sockets in TIME_WAIT:
File Descriptors
Busy servers and load generators may run out of file descriptors as the system defaults are normally low. These can be increased for a specific user in /etc/security/limits.conf:
Congestion Control
Linux supports pluggable congestion control algorithms. To get a list of congestion control algorithms that are available in your kernel run:
If cubic and/or htcp are not listed then you will need to research the control algorithms for your kernel. You can try setting the control to cubic with:
Mac OS
Windows
Seriously???
Network Tuning
- Intermediaries such as nginx can use non persistent HTTP/1.0 connection. Make sure that persistent HTTP/1.1 connections are used.
JVM Tuning
- Tune the Garbage Collection
- Allocate sufficient memory
- Use the -server option
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 queuewith 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.
Below is a sample configuration:
Configure the number of threads according to the webapp. That is, how many threads it needsin order to achieve the best performance. Configure with mind to limiting memory usage maximum available.Typically >50 and <500.
BBjServices integrates a Web Server based on the Eclipse project's server, Jetty. Jetty serves applications in production all over the world and is an industrial-strength solution. General server-wide configuration happens in Enterprise Manager. This type of configuration covers the server ports, hostname, and SSL configuration. BBj makes use of Jetty in a few different ways. The specific services are configured in other parts of Enterprise Manager, or within a BBj program. BUI, Web Start, Web Services, and the demos are all handled within Enterprise Manager.
By default, Jetty serves http requests on port 8888 and https requests on port 8443. To customize the ports from the Web Configuration:
ExpandBBjServices.
Double-clickServersin the BBj EM Navigator and the settings tab will open to the right.
Expand theWeb settingsto see the configurations.
Jetty, by default, logs to the request.log file in the logs directory. Each request to the Web Server generates a line in the logfile. Each line includes the IP address of the remote host, the time and date, and finally the http request. Logged information is not currently configurable.
Jetty serves any files in the htdocs directory under the /files path prefix. For example, the file BBj.png resides in the htdocs/images subdirectory of BBj home. To view that image directly in a web browser, navigate to localhost:8888/files/images/BBj.png (all paths are case sensitive).
By default, BUI applications are served under the /apps path prefix, but this path prefix can be altered under the Context Configuration . When the application named 'test' is published in Enterprise Manager, the application is reachable through localhost:8888/apps/test. BUI applications may be published programmatically as well.
By default, Web start applications are served under the /jnlp path prefix, but this path prefix can be altered under the Context Configuration. Applications are configured in the JNLP section of Enterprise Manager. Signed jars are also available from the /jnlp prefix. Any jar placed in the lib directory will be copied to a cache directory, compressed, and signed. Download BBjThinClient.jar directly from localhost:8888/jnlp/BBjThinClient.jar or the packed version from localhost:8888/jnlp/BBjThinClient.jar.pack.gz.
By default, Web Services are served from the /webservice path prefix, but this path prefix can be altered under the Context Configuration . Web Services are configured in the Web Service section of Enterprise Manager. Accessing a Web Service generally requires creating a specialized client to use the service. However, the WSDL (Web Service Description Language) file is available directly. The BUS Web Service is installed by default in BBj, accessible from localhost:8888/webservice/BUS?wsdl.
By default, BBjServlets are served from the /servlet path prefix but this path prefix can be altered under the Context Configurationand BBjServlets are deployed programmatically. See BBj Servlet Overview.
Demos, and built-in basis applications are available via the /basis prefix. Demos for Web start and BUI are available in their respective sections of EM. Enterprise Manager itself may be launched from localhost:8888/basis/em.jnlp.
Jetty is a powerful and complicated Web Server. BBj distills the complexity down to a few key features. Globally, BASIS provides SSL configuration and logging. These apply to all of the specific BBj web actions - file serving, Web Start, BUI Web Services, BBjServlet, and the BASIS demos.
Some of the more advanced aspects of the Jetty server by setting these properties within BBj.properties:
com.basis.jetty.allowAliases={true|false}
under the Linux operating system this property will tell Jetty to follow symbolic-links in the filesystem when serving content.com.basis.jetty.maxBufferSize={value}
changes the internal Jetty value that controls when content being served will become chunked and thus lose the content-size and content-type headers.The sims 3 all in one download pc. com.basis.jetty.maxFormKeys={value}
sets the maximum number of keys Jetty will accept in a POSTed http request.com.basis.jetty.macContentSize={value}
controls the maximum size of a POSTed http request that Jetty will accept.
See also
Jetty Web Server
______________________________________________________________________________________Jetty Server For Mac Windows 10
Copyright BASIS International Ltd. BBj®, Visual PRO/5®, PRO/5®, and BBx® are registered trademarks.
