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.
Thanks Jason.
Andy
----- Original Message -----
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
> > 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:
> 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
> > > 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
>
> >
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
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat