You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2015/01/09 18:25:31 UTC
Performance change
Hi,
Following the refactoring, performance is significantly down for NIO2, but
improved for NIO1.
With my ab test on tomcat.gif, logging disabled, this does (Tomcat 8 vs
trunk):
NIO1: 50k -> 60k
NIO2: 65k -> 57k
IMO the difference is significant, so this is a real regression. I didn't
really see anything obvious that could explain that. Maybe a combination of
the deque or the buffering behavior change ? Unless the cause is found and
this gets fixed, there would be few reasons to keep the NIO2 connector.
Rémy
Re: Performance change
Posted by Rémy Maucherat <re...@apache.org>.
2015-01-11 20:40 GMT+01:00 Mark Thomas <ma...@apache.org>:
> Just for info, I have found that none of the non-blocking IO (including
> that used by the WebSocket impl) was using the socket write buffer. I'm
> making good progress refactoring things so everything is buffered by
> default but it has triggered a lot of bugs that need fixing by inserting
> a ServletOutputStream.flush() at an appropriate point.
>
Yes, I noted some months ago that upgrade wasn't buffered, but it is not
necessarily a bug. Obviously buffering isn't going to hurt since the bytes
would be copied anyway.
>
> This might turn into something that causes apps issues (if indeed any
> apps at all are using the HTTP upgrade API). If this is the case we can
> add an option to always flush an upgraded OutputStream after a write but
> for now I plan to leave this as a TODO.
>
> My impressions of performance so far is good but I want to do some side
> by side comparisons of 8.0.x vs 9.0.x for various cases once I have the
> refactoring complete to see what the real differences are. If it turns
> out to be positive, I may see if I can structure an ApacheCon talk out
> of it.
>
> APR and NIO2 are now the same as in 8.x in my toy "benchamrk", and NIO is
still up. I doubt this makes any real world difference though, it's just a
quick check.
Rémy
Re: Performance change
Posted by Mark Thomas <ma...@apache.org>.
On 09/01/2015 23:57, Rémy Maucherat wrote:
> 2015-01-09 22:44 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>>> I made a mistake, which also made me think that the NIO connector didn't
>>> suffer from the NPE. In the end, there's no significant improvement
>> there.
>>
>> That matches my results. NIO is about the same in 8.0.x and 9.0.x for me.
>>
>>>> The other thing to keep in mind is that these performance figures could
>>>> easily shift a lot further as the code clean-up continues. We should
>>>> defer any decision about removing an implementation until after the
>>>> refactoring is complete. Looking further ahead, the HTTP/2 work may
>>>> impact performance as well.
>>>>
>>>> On balance I think we should keep all three implementations since there
>>>> are always likely to be loads that are better suited to one
>>>> implementation than the others.
>>>>
>>> No problem with that.
>>
>> Bingo. The tweaks I made might have provided a few % points but it is
>> the buffering that makes all the difference. I have a local hack that
>> restores it for NIO2 and performance immediately goes up by ~15%. Rather
>> than commit this hack, I am going to work on a more general fix. I
>> should have something early next week.
>>
> Ok, good to know. I wonder if the NIO connector IO is optimal, I'll have
> some time to look at it relatively soon, probably.
Just for info, I have found that none of the non-blocking IO (including
that used by the WebSocket impl) was using the socket write buffer. I'm
making good progress refactoring things so everything is buffered by
default but it has triggered a lot of bugs that need fixing by inserting
a ServletOutputStream.flush() at an appropriate point.
This might turn into something that causes apps issues (if indeed any
apps at all are using the HTTP upgrade API). If this is the case we can
add an option to always flush an upgraded OutputStream after a write but
for now I plan to leave this as a TODO.
My impressions of performance so far is good but I want to do some side
by side comparisons of 8.0.x vs 9.0.x for various cases once I have the
refactoring complete to see what the real differences are. If it turns
out to be positive, I may see if I can structure an ApacheCon talk out
of it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Performance change
Posted by Rémy Maucherat <re...@apache.org>.
2015-01-09 22:44 GMT+01:00 Mark Thomas <ma...@apache.org>:
> > I made a mistake, which also made me think that the NIO connector didn't
> > suffer from the NPE. In the end, there's no significant improvement
> there.
>
> That matches my results. NIO is about the same in 8.0.x and 9.0.x for me.
>
> >> The other thing to keep in mind is that these performance figures could
> >> easily shift a lot further as the code clean-up continues. We should
> >> defer any decision about removing an implementation until after the
> >> refactoring is complete. Looking further ahead, the HTTP/2 work may
> >> impact performance as well.
> >>
> >> On balance I think we should keep all three implementations since there
> >> are always likely to be loads that are better suited to one
> >> implementation than the others.
> >>
> > No problem with that.
>
> Bingo. The tweaks I made might have provided a few % points but it is
> the buffering that makes all the difference. I have a local hack that
> restores it for NIO2 and performance immediately goes up by ~15%. Rather
> than commit this hack, I am going to work on a more general fix. I
> should have something early next week.
>
> Ok, good to know. I wonder if the NIO connector IO is optimal, I'll have
some time to look at it relatively soon, probably.
Rémy
Re: Performance change
Posted by Mark Thomas <ma...@apache.org>.
On 09/01/2015 19:13, Rémy Maucherat wrote:
> 2015-01-09 18:45 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>> One reason (once all the refactoring is complete) might be WebSocket
>> since the use of CompletionHandlers in WebSocket and NIO2 may allow for
>> some efficiencies that just aren't possible with NIO or APR.
>>
>
> We'll see.
>
>>
>> I'll add looking at this to my TODO list. Unfortunately, past experience
>> suggests tuning this may involve more guess work than I'd like since at
>> these sorts of rates profilers tend to add so much overhead you can't
>> find the bottleneck you are looking for.
>>
>
> I made a mistake, which also made me think that the NIO connector didn't
> suffer from the NPE. In the end, there's no significant improvement there.
That matches my results. NIO is about the same in 8.0.x and 9.0.x for me.
>> The other thing to keep in mind is that these performance figures could
>> easily shift a lot further as the code clean-up continues. We should
>> defer any decision about removing an implementation until after the
>> refactoring is complete. Looking further ahead, the HTTP/2 work may
>> impact performance as well.
>>
>> On balance I think we should keep all three implementations since there
>> are always likely to be loads that are better suited to one
>> implementation than the others.
>>
> No problem with that.
Bingo. The tweaks I made might have provided a few % points but it is
the buffering that makes all the difference. I have a local hack that
restores it for NIO2 and performance immediately goes up by ~15%. Rather
than commit this hack, I am going to work on a more general fix. I
should have something early next week.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Performance change
Posted by Rémy Maucherat <re...@apache.org>.
2015-01-09 18:45 GMT+01:00 Mark Thomas <ma...@apache.org>:
> One reason (once all the refactoring is complete) might be WebSocket
> since the use of CompletionHandlers in WebSocket and NIO2 may allow for
> some efficiencies that just aren't possible with NIO or APR.
>
We'll see.
>
> I'll add looking at this to my TODO list. Unfortunately, past experience
> suggests tuning this may involve more guess work than I'd like since at
> these sorts of rates profilers tend to add so much overhead you can't
> find the bottleneck you are looking for.
>
I made a mistake, which also made me think that the NIO connector didn't
suffer from the NPE. In the end, there's no significant improvement there.
>
> The other thing to keep in mind is that these performance figures could
> easily shift a lot further as the code clean-up continues. We should
> defer any decision about removing an implementation until after the
> refactoring is complete. Looking further ahead, the HTTP/2 work may
> impact performance as well.
>
> On balance I think we should keep all three implementations since there
> are always likely to be loads that are better suited to one
> implementation than the others.
>
> No problem with that.
Rémy
Re: Performance change
Posted by Mark Thomas <ma...@apache.org>.
On 09/01/2015 17:25, Rémy Maucherat wrote:
> Hi,
>
> Following the refactoring, performance is significantly down for NIO2, but
> improved for NIO1.
>
> With my ab test on tomcat.gif, logging disabled, this does (Tomcat 8 vs
> trunk):
> NIO1: 50k -> 60k
up 20% wow
> NIO2: 65k -> 57k
down 15% :( not so good
> IMO the difference is significant, so this is a real regression.
Agreed.
> I didn't really see anything obvious that could explain that.
Likewise.
> Maybe a combination of the deque or the buffering behavior change?
I agree that these are the most likely candidates.
> Unless the cause is found and
> this gets fixed, there would be few reasons to keep the NIO2 connector.
One reason (once all the refactoring is complete) might be WebSocket
since the use of CompletionHandlers in WebSocket and NIO2 may allow for
some efficiencies that just aren't possible with NIO or APR.
I'll add looking at this to my TODO list. Unfortunately, past experience
suggests tuning this may involve more guess work than I'd like since at
these sorts of rates profilers tend to add so much overhead you can't
find the bottleneck you are looking for.
The other thing to keep in mind is that these performance figures could
easily shift a lot further as the code clean-up continues. We should
defer any decision about removing an implementation until after the
refactoring is complete. Looking further ahead, the HTTP/2 work may
impact performance as well.
On balance I think we should keep all three implementations since there
are always likely to be loads that are better suited to one
implementation than the others.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org