Why Use Jetty?

转载：https://www.webtide.com/choose/jetty.jsp

 

There are several open source HTTP servers and Servlet Containers available: Jetty, Tomcat, Glassfish, Resin, so a frequently asked question is why use Jetty rather than one of these alternatives. This paper is short overview of the technical and non-technical drivers of a decision to use Jetty.

Performance

Performance is very important for every web business, no matter how many requests per second they need to serve. However, when measuring performance it is important to know which performance metrics are valid for your site and that they are being correctly measured.

Page Load Time

If a site is handling less than many 1000s of requests per second, then thoughput (requests per second) is unlikely to be an important metric. Instead, studies have shown that slow pages can reduce revenue and conversions from a web site by up to 15%, so minimising page load time is the performance metric applicable for many (most) sites.

Jetty's focus on multi-connection HTTP and features such as SPDY (and soon HTTP/2.0) can significantly reduce page load latencies without the need to re-engineer your web application.

Small Memory Footprint

Jetty has been designed to have a small memory foot print, which is an excellent basis for good all round performance and scalability. If the server users less memory, then there is more memory available for the application, threads and caches. Also having more free memory can greatly improve garbage collection and improve all round application performance. A small memory footprint allows more instances of the server to be run on virtual hardware, which is often memory constrained, making Jetty very cloud friendly.

Throughput

If your website does need to handle many 1000s of requests per second, then it is very important to understand that there is a big difference between serving 10,000 requests per second over 1 TCP/IP connection vs serving the same request rate over 10,000 connections. Many published or self performed benchmarks consist of open a few connections and sending as many requests as possible over them. This is a poor measure of throughput because it is based on a load profile which is unlike the vast majority of loads experienced by real web servers. Such tests simulate a few extraordinarily busy users, when most typical web sites will see many simultaneous users who send requests in short bursts separated by idle periods. The impact that such different load profiles can have on performance results is discussed in Lies, damned lies and benchmarks.

Jetty has been designed for scalable performance under realistic loads of many simultaneous connections and we can achieve excellent results with many 10s of thousands of HTTP connections and 100s of thousands of simultaneous websocket connections.

Most importantly, because our benchmarks are based on real applications under realistic loads, we have real users that have achieve the same results in production.

Innovation

The web is a moving target when it comes to deploying applications that will meet users expectations of usability and interactivity. There has been a continual evolution of technique and protocols frombasic web pages, CSS, javascript, Ajax, Web 2.0, Comet, Websocket, HTML5, SPDY and soonHTTP/2.0. Each new technique can dramatically change the load profile experienced by the server and new protocols must be supported by the server.

Market Share

The web has proved time and time again that users are fickle and that massive market share can be lost/gained very quickly depending on usability and availability of the latest web features. Thus in order to develop a successful web application and to keep an already successful web application current and relevant, it is vital that your server will allow you to keep up with the latest techniques and protocols.

Jetty was the first HTTP server developed in Java (1991), long before the servlet specification and has been at the fore front of web development since then. Jetty has either lead or been among the first movers on many significant innovations: HTTP/1.1, Asynchronous servlets, comet, websocket, SPDY, and soon HTTP/2.0. If you want to keep your market share from migrating away to follow the latest web developments, then using Jetty will give you a platform on which you can stay current.

Stability

Typically new advanced features are made available in the current stable release of Jetty as optional extras before being made core features in the next major release. For example, as the browser support for websockets and SPDY was rolled out through 2011 and 2012, Jetty made support for these available in Jetty-7 and Jetty-8 as additions while simultaneously we re-architected jetty-9 to have these important technologies built into the core server, not just as adjuncts. This allows your development team to experiment and innovate with new features without subjecting your application to a major version upgrade.

Collaboration

The jetty project is receptive to new ideas and is somewhere you can bring your own ideas to fruition. For example, Asynchronous servlets were first developed as a result of suggestions from the activemq project, who had been told by other open source server projects that the suggested use-case was a protocol abuse and should not be done in a java application server. Asynchronous servlets are now part of the servlet specification and activemq have enjoyed the scalability benefits longer than most by using jetty.

Standards

The flip side of innovation can be vendor lock in if a feature is only available on a single server. The Jetty project is keenly aware that we want users to use Jetty because they want to, not because they have to, thus we make every effort to adopt standards and avoid proprietary APIs and extensions. Jetty developers are active in the JCP and IETF where we participate in the development of Internet standards. This allows us to be early implementors of new standards (eg Servlet 3.0, websocket), or to work towards standardization of our own innovations (asynchronous servlets).

Currently we have deployed websocket support using a Jetty API, but are working with the JCP on a standard websocket API that will soon be supported

Architecture

The view from 20,000 feet is that Jetty and the other containers are rather similar, they are all java applications servers offering implementations of the 2.5/3.0 servlet specification with optional extras giving many JEE features. You can drop a standard WAR file into all of these servers and expect them to run, so in many ways all the servers are commodity products and for many webapps it is not important which you use.

However, on closer inspection, the architectures of the servers differ greatly, mostly because each project as historically had a different focus. Unlike the other contains, Jetty was not developed to be first and foremost and application server. Application servers have the benefit of controlling the majority of their environment and enforcing that deployed applications adhere to their conventions and standards. This is great if you want a commodity server, but can lack flexibility if you need to operate outside of the commodity box.

Jetty is first and foremost a set of software components built to offer HTTP and servlet services. These components can be assembled as needed to form a purpose built server, include as an Application server. One of the jetty design mottoes has been: "Don't put your application into Jetty, put Jetty into your Application". The benefits of this approach include:

• One size does not fit all. While jetty can (and has been) used as the web tier of full and partial JEE stacks ( Geronimo, Jboss, Sybase EAServer, JonAS, Glassfish and Hightide), such stacks are not the only "solution" required for application servers. Thus Jetty has also been used as the basis for other application frameworks including: SIP telephony (www.cipango.org), Ajax JMS (www.activemq.org), Asynchronous SOA services (Apache Camel)

• There is "no taxation without representation". Because features like JMX, JNDI, annotations and JEE integration are implemented as pluggable and/or extended components, then if there is no need for a particular feature then it does not need to be assembled and the server does not have to pay a memory/CPU cost for an unused feature. While other servers can also be stripped back to lighterweight cores, it is often harder to strip back complexity than it is to simply add what you need.

• As a collection of assembled software components, it is very simple to extend and/or replace components with customized behavior. For example, when Google chose Jetty as the servlet container for AppEngine, they were able to easily plugin their own HTTP connector and session management extensions. Similarly the integration of Jetty into development tools like maven can be very flexible as the components that control the layout of a webapp can be updated to run an unassembled application from source rather than an assembled WAR. For example the mvn jetty:run plugin can be used to run a maven webapp project from source, without assembly.

• All APIs are public. Every module of Jetty could be used by a Jetty user as part of an extended/pluggable solution. Thus there is no scope at all for Jetty developers to be lazy with their designs/implementations and under the covers, Jetty code is easily understandable and maintainable.

• Development tools and frameworks often take advantage of the embeddable nature of Jetty: Google Widget Toolkit, Grails, Eclipse, OSGi Equinox, OSGi Felix, Maven, Continuum, Fisheye, Jruby, Xbean, Tapestry, Cocoon, Plexus etc. all either use Jetty by default or have Jetty bindings. Thus when it comes to production, it makes sense to run your application on the same server that was used to develop it.

Support and Community

Sometimes using the best technology can still be tough if you are the only one doing so and are unsupported. Jetty is an open source project with the normal community support lists, but it is also well represented in collaborative support systems like stack overflow.

For commercial support, Intalio|Webtide provides developer advice, which is focused on answering your developers questions during development so that production problems can be avoided; and production support that helps diagnose and fix any issues on your live servers. We can also assist you with custom jetty developments and extensions.