You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Brett Humphreys <br...@google.com> on 2013/10/21 18:38:53 UTC
Jetty SSL Performance
Hi all,
This may be a bit off the wall, but I'm trying to squeeze out the most
performance out of Jetty that I can. However I have some constraints that
I can't change in the near term. Specifically:
1. I'm using a relatively ancient version of CXF (2.2.12)
2. I'm *not* using keep-alive
What I'd like to reach is about 180 SOAP operations per second (OPS) on
this jetty server, which is simulating a 3rd party server. It seems that
it takes Jetty ~350ms to negotiate the SSL connection. So what I'm seeing
is I get about 3 (technically 2.96 consistently) SOAP OPS with the Jetty
instance. If I turn on keep-alives, then my performance goes through the
roof (I see it take about ~20ms, but I think this is multithreaded) to
about 150 SOAP OPS.
So without any heroics, is there a way that I can push jetty to get better
performance without setting keep-alives to true on my client?
The reason for lack of keep alive connections is I'm trying to make sure
that under load I can still negotiate the SSL connections. Since I talk to
third parties through this interface I don't want to assume they'll have
keep-alives turned on.
FWIW, I also have client authentication turned on.
Here's some relevant config about my server:
ClientAuthentication clientAuth = new ClientAuthentication();
clientAuth.setRequired(true);
clientAuth.setWant(true);
I'm using very small keystores and truststores (1-2 entries each). And I
have the TLS cipher suites limited to a dozen or so trusted cipher suites.
Thanks!
Brett Humphreys
Re: Jetty SSL Performance
Posted by Brett Humphreys <br...@google.com>.
Thanks Daniel for your quick response
I agree with all your statements about ancient versions and keep-alives.
Regarding throwing more threads at the problem. I attempted to set:
int maxThreads = 500;
ThreadingParameters threadingParameters = new ThreadingParameters();
threadingParameters.setMaxThreads(maxThreads);
threadingParameters.setMinThreads(maxThreads / 2);
However this didn't really change my performance profile. It seems that
these threads are post-negotiation. Is there a knob that I can turn to
change the number of acceptor threads in order to multi thread negotiation?
On Mon, Oct 21, 2013 at 10:59 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> On Oct 21, 2013, at 12:38 PM, Brett Humphreys <br...@google.com>
> wrote:
>
> > Hi all,
> > This may be a bit off the wall, but I'm trying to squeeze out the most
> > performance out of Jetty that I can. However I have some constraints
> that
> > I can't change in the near term. Specifically:
> >
> > 1. I'm using a relatively ancient version of CXF (2.2.12)
> > 2. I'm *not* using keep-alive
> >
> > What I'd like to reach is about 180 SOAP operations per second (OPS) on
> > this jetty server, which is simulating a 3rd party server. It seems that
> > it takes Jetty ~350ms to negotiate the SSL connection. So what I'm
> seeing
> > is I get about 3 (technically 2.96 consistently) SOAP OPS with the Jetty
> > instance. If I turn on keep-alives, then my performance goes through the
> > roof (I see it take about ~20ms, but I think this is multithreaded) to
> > about 150 SOAP OPS.
> >
> > So without any heroics, is there a way that I can push jetty to get
> better
> > performance without setting keep-alives to true on my client?
>
> Likely not. SSL connections are very expensive to setup and create.
> As you see, 350ms is likely about right for negotiating the SSL connection.
> When using HTTPs, you really need to use Keep-Alives.
>
> Also, with CXF version that old, you're likely using the old old version
> of Jetty that doesn't use NIO for the SSL connectors. Thus, the Jetty
> threads are blocked throughout that process. Throwing more threads at it
> to allow additional simultaneous negotiations may help a little, but
> definitely not an ideal situation.
>
> I definitely suggest updating to a newer CXF (and newer Jetty). The
> newer Jetty has much better threading controls and defaults that would at
> least allow additional simultaneous connections.
>
> Dan
>
>
>
> > The reason for lack of keep alive connections is I'm trying to make sure
> > that under load I can still negotiate the SSL connections. Since I talk
> to
> > third parties through this interface I don't want to assume they'll have
> > keep-alives turned on.
> >
> > FWIW, I also have client authentication turned on.
> >
> > Here's some relevant config about my server:
> >
> > ClientAuthentication clientAuth = new ClientAuthentication();
> > clientAuth.setRequired(true);
> > clientAuth.setWant(true);
> >
> > I'm using very small keystores and truststores (1-2 entries each). And I
> > have the TLS cipher suites limited to a dozen or so trusted cipher
> suites.
> >
> > Thanks!
> >
> > Brett Humphreys
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Brett Humphreys | Software Engineer, Carrier Billing Technical Lead |
bretthumphreys@google.com | 720-663-9479
Re: Jetty SSL Performance
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 21, 2013, at 12:38 PM, Brett Humphreys <br...@google.com> wrote:
> Hi all,
> This may be a bit off the wall, but I'm trying to squeeze out the most
> performance out of Jetty that I can. However I have some constraints that
> I can't change in the near term. Specifically:
>
> 1. I'm using a relatively ancient version of CXF (2.2.12)
> 2. I'm *not* using keep-alive
>
> What I'd like to reach is about 180 SOAP operations per second (OPS) on
> this jetty server, which is simulating a 3rd party server. It seems that
> it takes Jetty ~350ms to negotiate the SSL connection. So what I'm seeing
> is I get about 3 (technically 2.96 consistently) SOAP OPS with the Jetty
> instance. If I turn on keep-alives, then my performance goes through the
> roof (I see it take about ~20ms, but I think this is multithreaded) to
> about 150 SOAP OPS.
>
> So without any heroics, is there a way that I can push jetty to get better
> performance without setting keep-alives to true on my client?
Likely not. SSL connections are very expensive to setup and create. As you see, 350ms is likely about right for negotiating the SSL connection. When using HTTPs, you really need to use Keep-Alives.
Also, with CXF version that old, you're likely using the old old version of Jetty that doesn't use NIO for the SSL connectors. Thus, the Jetty threads are blocked throughout that process. Throwing more threads at it to allow additional simultaneous negotiations may help a little, but definitely not an ideal situation.
I definitely suggest updating to a newer CXF (and newer Jetty). The newer Jetty has much better threading controls and defaults that would at least allow additional simultaneous connections.
Dan
> The reason for lack of keep alive connections is I'm trying to make sure
> that under load I can still negotiate the SSL connections. Since I talk to
> third parties through this interface I don't want to assume they'll have
> keep-alives turned on.
>
> FWIW, I also have client authentication turned on.
>
> Here's some relevant config about my server:
>
> ClientAuthentication clientAuth = new ClientAuthentication();
> clientAuth.setRequired(true);
> clientAuth.setWant(true);
>
> I'm using very small keystores and truststores (1-2 entries each). And I
> have the TLS cipher suites limited to a dozen or so trusted cipher suites.
>
> Thanks!
>
> Brett Humphreys
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com