What are Jetty 9s most performant APIs to use?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

What are Jetty 9s most performant APIs to use?

Danny
I am upgrading a Jetty 7 based embedded server to Jetty 9 (v 9.1.4 – 9.2.0 when released) in a same effort of upgrading to Java 8. I intend to optimize it in the process to serve out famo.us type of JavaScript for 3D web-sites (HTML5/CCS3/JS) and some SVG without any plug-ins at the client side (WebGL) and of course dynamic data coming from backbone components such as databases. This results in a mix of many short effort/waiting responses and some longer. So I definitely go for a non-blocking approach.

While the Java 8 upgrade was quite easy I find myself for a difficult decision when it comes to Jetty. In version 7 I used the NIO and selector interfaces to get Asynchrony but these classes do no longer exist in Jetty 9. I have been digging in the new Jetty 9 docs, on this Nabble User and this Dev board and have read the articles on Webtide on Jetty-9’s Iterating Asynchronous Callbacks, on the performance benchmarks and looked into the docs sample code as well as the benchmark Java code on GitHub.

I found on this board that migrating from Jetty 7 to 9 needs a lot of rewriting (as others have asked the question before). But since I learned about the many improvements in the assync interface of Jetty 9 I decided to do the effort of rewriting a completely new Jetty 9 based embedded Assync server with SSL/NPN/SPDY3/2/HTTP  (hopefully HTTP2.0 ready to add it later) and Websock server and client using the Jetty classes/APIs that give me the highest possible  performance.

As a side note, congrats to all you guys that have put down that Jetty 9 performance. As gregw correctly points out and demonstrates with the graphs in the benchmark article it makes no sense being able to accept a ridiculous number of hits if you can’t server them out in a ‘workable’ response time to affect the client side screen.

The help or advise I am looking for via this post is in finding the components in Jetty 9 to use, or even better an example of a server frame, that would be considered by the Jetty team as the one using the most performant APIs/approach possible in Jetty 9. The benchmark code is fast according the Webtide article but it states explicitly it doesn’t “EVEN” use Jetty’s most performant APIs. Other assync related articles mention the QueuedThreadPool, Jetty 9s IO Callbacks and Itterating Callbacks but the examples where separated from a complete frame example showing their relation to selected Server options, connectors and so making it difficult to see/know if all this combines with it the SLL/SPDY/HTTP/Web Sock connectors and where or how you activate/select this working mode.

I started working from the “Example 25.4. SpdyServer.java” example of the Jetty 9 docs with static max thread pools, because after reading the comments inside Jetty’s  ServerConnector class source code http://download.eclipse.org/jetty/stable-9/xref/org/eclipse/jetty/server/ServerConnector.html I thought that was all I needed. However gregw’s Webtide articles demonstrated I was not using Jetty’s most performant API’s. As you guys did all this effort to create this new Jetty 9 I might as well do the effort in rewriting my code from scratch to get the best out of Jetty.

I would appreciate some pointers, help or advice to show me the way.

TIA
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] What are Jetty 9s most performant APIs to use?

Greg Wilkins-5
Danny,

sorry for slow response.

With Jetty-9, there is really only the ServerConnector and it is asynchronous.  It can be configured with different connection factories for HTTP, SSL, SPDY etc.
The ServerConnector is our most performant connector.

A good place to look for examples is in the embedded examples in the jetty source tree.  There you will find simple servers put together.  This doco is also helpful: https://www.eclipse.org/jetty/documentation/current/embedding-jetty.html

cheers



On 10 May 2014 18:57, Danny <[hidden email]> wrote:
I am upgrading a Jetty 7 based embedded server to Jetty 9 (v 9.1.4 – 9.2.0
when released) in a same effort of upgrading to Java 8. I intend to optimize
it in the process to serve out famo.us type of JavaScript for 3D web-sites
(HTML5/CCS3/JS) and some SVG without any plug-ins at the client side (WebGL)
and of course dynamic data coming from backbone components such as
databases. This results in a mix of many short effort/waiting responses and
some longer. So I definitely go for a non-blocking approach.

While the Java 8 upgrade was quite easy I find myself for a difficult
decision when it comes to Jetty. In version 7 I used the NIO and selector
interfaces to get Asynchrony but these classes do no longer exist in Jetty
9. I have been digging in the new Jetty 9 docs, on this Nabble User and this
Dev board and have read the articles on Webtide on Jetty-9’s Iterating
Asynchronous Callbacks, on the performance benchmarks and looked into the
docs sample code as well as the benchmark Java code on GitHub.

I found on this board that migrating from Jetty 7 to 9 needs a lot of
rewriting (as others have asked the question before). But since I learned
about the many improvements in the assync interface of Jetty 9 I decided to
do the effort of rewriting a completely new Jetty 9 based embedded Assync
server with SSL/NPN/SPDY3/2/HTTP  (hopefully HTTP2.0 ready to add it later)
and Websock server and client using the Jetty classes/APIs that give me the
highest possible  performance.

As a side note, congrats to all you guys that have put down that Jetty 9
performance. As gregw correctly points out and demonstrates with the graphs
in the benchmark article it makes no sense being able to accept a ridiculous
number of hits if you can’t server them out in a ‘workable’ response time to
affect the client side screen.

The help or advise I am looking for via this post is in finding the
components in Jetty 9 to use, or even better an example of a server frame,
that would be considered by the Jetty team as the one using the most
performant APIs/approach possible in Jetty 9. The benchmark code is fast
according the Webtide article but it states explicitly it doesn’t “EVEN” use
Jetty’s most performant APIs. Other assync related articles mention the
QueuedThreadPool, Jetty 9s IO Callbacks and Itterating Callbacks but the
examples where separated from a complete frame example showing their
relation to selected Server options, connectors and so making it difficult
to see/know if all this combines with it the SLL/SPDY/HTTP/Web Sock
connectors and where or how you activate/select this working mode.

I started working from the “Example 25.4. SpdyServer.java” example of the
Jetty 9 docs with static max thread pools, because after reading the
comments inside Jetty’s  ServerConnector class source code
http://download.eclipse.org/jetty/stable-9/xref/org/eclipse/jetty/server/ServerConnector.html
I thought that was all I needed. However gregw’s Webtide articles
demonstrated I was not using Jetty’s most performant API’s. As you guys did
all this effort to create this new Jetty 9 I might as well do the effort in
rewriting my code from scratch to get the best out of Jetty.

I would appreciate some pointers, help or advice to show me the way.

TIA




--
View this message in context: http://jetty.4.x6.nabble.com/What-are-Jetty-9s-most-performant-APIs-to-use-tp4962539.html
Sent from the Jetty Dev mailing list archive at Nabble.com.
_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] What are Jetty 9s most performant APIs to use?

Danny
Greg,
Thanks for the reply.

I did indeed go for ServerConnector and combined it with Continuations to achieve thread-less waiting. It works fine even with Thread Pools of the minimum size (10) threads.  

Is there any chance that in future versions of Jetty the minimum # threads in the pool may be lower then 10 so that they can be set  equal to the number of CPU cores. Lesser threads seem to work faster.

Also because for small foot-print embedded servers (e.g. Occasional low frequency browser access to a Raspberry Pi  that is part of a home automation system) 10 threads is overkill.  

TIA
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] What are Jetty 9s most performant APIs to use?

Greg Wilkins-5
Danny,

there is no 10 thread minimum in the thread pool.

There are errors generated if there are insufficient thread for the acceptors/selectors, but you can configure your connector to have only 1 of each of these.

For example the following code starts a server fine:

        QueuedThreadPool qtp = new QueuedThreadPool(4, 1);
        Server server = new Server(qtp);
        ServerConnector connector = new ServerConnector(server, 1, 1);
        connector.setPort(8080);
        server.addConnector(connector);
        server.setHandler(new HelloHandler());

        server.start();
        server.dumpStdErr();
        server.join();


eg.

2014-07-09 13:24:10.420:INFO::main: Logging initialized @107ms
2014-07-09 13:24:10.488:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
2014-07-09 13:24:10.531:INFO:oejs.ServerConnector:main: Started ServerConnector@4ac93274{HTTP/1.1}{0.0.0.0:8080}
2014-07-09 13:24:10.532:INFO:oejs.Server:main: Started @244ms
org.eclipse.jetty.server.Server@2784de18 - STARTED
 += qtp155724457{STARTED,1<=3<=4,i=1,q=0} - STARTED
 |   +- 9 qtp155724457-9-selector-ServerConnectorManager@272c6f83/0 RUNNABLE @ sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
 |   +- 11 qtp155724457-11-acceptor-0-ServerConnector@4ac93274{HTTP/1.1}{0.0.0.0:8080} RUNNABLE @ sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
 |   +- 12 qtp155724457-12 TIMED_WAITING @ sun.misc.Unsafe.park(Native Method) IDLE
 += ServerConnector@4ac93274{HTTP/1.1}{0.0.0.0:8080} - STARTED
 |   +~ org.eclipse.jetty.server.Server@2784de18 - STARTED
 |   +~ qtp155724457{STARTED,1<=3<=4,i=1,q=0} - STARTED
 |   += org.eclipse.jetty.util.thread.ScheduledExecutorScheduler@642daf7a - STARTED
 |   +- org.eclipse.jetty.io.ArrayByteBufferPool@1b523bd4
 |   += HttpConnectionFactory@33d5e94f{HTTP/1.1} - STARTED
 |   |   +- HttpConfiguration@20c85c1f{32768,8192/8192,https://:0,[]}
 |   += org.eclipse.jetty.server.ServerConnector$ServerConnectorManager@272c6f83 - STARTED
 |   |   +- org.eclipse.jetty.io.SelectorManager$ManagedSelector@751bd80c keys=0 selected=0 id=0
 |   |       +- org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:538)
 |   |       +- sun.nio.ch.EPollSelectorImpl@2da75e1b keys=0
 |   +- sun.nio.ch.ServerSocketChannelImpl[/0:0:0:0:0:0:0:0:8080]
 += org.eclipse.jetty.embedded.HelloHandler@1ac0bc3a - STARTED





On 1 July 2014 20:51, Danny <[hidden email]> wrote:
Greg,
Thanks for the reply.

I did indeed go for ServerConnector and combined it with Continuations to
achieve thread-less waiting. It works fine even with Thread Pools of the
minimum size (10) threads.

Is there any chance that in future versions of Jetty the minimum # threads
in the pool may be lower then 10 so that they can be set  equal to the
number of CPU cores. Lesser threads seem to work faster.

Also because for small foot-print embedded servers (e.g. Occasional low
frequency browser access to a Raspberry Pi  that is part of a home
automation system) 10 threads is overkill.

TIA



--
View this message in context: http://jetty.4.x6.nabble.com/What-are-Jetty-9s-most-performant-APIs-to-use-tp4962539p4962732.html
Sent from the Jetty Dev mailing list archive at Nabble.com.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev