On 06/16/2015 04:08 PM, Andrig T. Miller wrote:
Okay. I don't have a problem with the openssl part of things,
just
didn't want to see effort expended on APR, as it was mentioned in a
different e-mail thread.
I think we are on the same page APR is useless without OpenSSL, the APR
connector won't make sense in undertow.
The new thing I have just merged in tc-native allows to use NIO/NIO2
with OpenSSL, Remy has the code for the NIO/NIO2 connectors of Tomcat
that should be portable to undertow.
Cheers
Jean-Frederic
Thanks Jason.
Andy
------------------------------------------------------------------------
*From: *"Jason Greene" <jason.greene(a)redhat.com>
*To: *"Andrig T. Miller" <anmiller(a)redhat.com>
*Cc: *"undertow-dev" <undertow-dev(a)lists.jboss.org>
*Sent: *Monday, June 15, 2015 12:01:42 PM
*Subject: *Re: [undertow-dev] Question about APR based connector in
Undertow
Oh and I forgot to mention that IMO I think we should prefer
contributing optimizations back to the JDK if at all possible, and
if not it should be the long term goal.
On Jun 15, 2015, at 12:51 PM, Jason Greene
<jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote:
We have no intention to do an APR connector. We have had some
occasional discussions about whether or not we will need openssl
support. Perhaps that’s where it is coming from?
JFC and Remy had some numbers on JBossWeb that showed poor perf
on JSSE vs OpenSSL using APR. It’s somewhat apples vs oranges
but looking at the JSSE impl we do see a number of
inefficiencies. As an example JSSE seems to do a lot of copying
(e.g. anything in a buffer becomes many byte arrays which gets
copied again to a buffer). We also see that SHA support on intel
is still in a big chunk of java code, and not intrinsic, wheras
on openssl its optimized assembler. The new AES GCM ciphers are
also known to be slow, but Andrew Haley mentioned that he is in
the process of optimizing those. All of this is of course,
anecdotal, and until we spend some cycles doing a more apples to
apples test I don’t think we can conclude this is a necessary
direction.
The other case where this might matter is how we find a way to
support HTTP2. HTTP2 requires that we support the ALPN extension
to TLS. Unfortunately JSSE has no support for it, and has been
rather slow to implement, and it has to come into 9 before there
is any possibility of a backport to 8:
http://openjdk.java.net/jeps/244
https://bugs.openjdk.java.net/browse/JDK-8051498
In the meantime we have been reusing a hack that the Jetty guys
are maintaining as a separate project, and it requires using
bootclasspath to replace core JSSE classes. These hacks are not
z-stream compatible, so any JDK bug fix update can break the
hack (and this has already happened about 2-3 times).
So on that perspective we have three options:
1) Red Hat does a Red Hat only hack for IcedTea distributions
(not sure if the JDK team would be willing to maintain it or
not, would have to ask)
2) Introduce openssl support, which supports ALPN
3) Wait for JSSE, and live with the hack (warning people
appropriately)
At this point, I don’t think we can commit to having anything
for the WildFly 10 schedule, unless the performance difference
really mandates such a thing, and then we might have to shuffle
things around.
On Jun 15, 2015, at 12:29 PM, Andrig T. Miller
<anmiller(a)redhat.com <mailto:anmiller@redhat.com>> wrote:
I am hearing that some work is being put into an APR based
connector for Undertow. I am wondering why we are doing this?
Based on my own testing, and testing the performance team
has done with AS 7.x/EAP 6.x/Wildfly, I see no performance
reason to do it, and it creates more work for getting
product out the door, and maintaining product.
We have found that the APR based connector can exhibit very
poor scalability, and consume large amounts of CPU resources
when in a network environment that is having problems (TCP
resets, dropped and retransmitted packets, etc.).
In this situation, especially where we see these poor
network conditions, the APR connector spends a lot of its
time managing the connection data structure. That data
structure is a ring (doubly linked list with head and tail
pointing at each other, which you already know). That ring
is sequentially searched for the socket to remove and it
locks all access with a mutex before it does this. This
causes both a CPU consumption issue, as it sequentially
walks the linked list, and a blocking problem. When we
first discovered this, I went into the code to see how easy
it would be to change it. I don't think this is a simple
fix, and since APR is the underpinning of other things, like
Apache HTTPD, not a trivial thing to get accepted by the
community either. This spurred us to look at the NIO2 based
connector, which at the time was unsupported, and it didn't
exhibit any of this poor behavior. That's what spurred the
effort to move the NIO2 based connector to be fully supported.
In the absence of poor network conditions, the APR connector
behaves and performs well, but in the presence of poor
network conditions its not good. So, with a viable
alternative, which Undertow provides out of the box with its
XNIO based architecture, there simple seems no good reason
to do with for Undertow.
Thanks.
--
Andrig (Andy) T. Miller
Global Platform Director, JBoss Middleware
Red Hat, Inc.
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
<mailto:undertow-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev