You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Christophe JAILLET <ch...@wanadoo.fr> on 2015/05/08 09:44:42 UTC
SO_REUSEPORT
Hi,
The SO_REUSEPORT patch has been in trunk for a few months now and has
been proposed for backport in 2.4.x.
Here is an interesting paper which gives a clear explanation and some
benchmark results:
http://www.intel.ie/content/dam/www/public/us/en/documents/white-papers/scaling-apache-server-performance-paper.pdf
Would be great if it could be committed in 2.4.x.
Having it reviewed and tested for 2.4.13 may not be possible because of
the T&R window which seems to be in the coming days/weeks.
(this already what was answered for the 2.4.11/2.4.12 release)
Maybe, 2.4.14 could focus on reviewing/merging this patch and associated
performance improvement?
To help adoption, maybe an ASF server could be upgraded with a
SO_REUSEPORT patched version of Apache to have our own measurements and
see how it scales in a real world application.
This has already been done in the past (testing impact of the skiplist
implementation).
Best regards,
CJ
Re: SO_REUSEPORT
Posted by Jim Jagielski <ji...@jaguNET.com>.
Actually, I was going to test that exact patch this weekend, in hopes
of getting it into 2.4
> On May 8, 2015, at 3:44 AM, Christophe JAILLET <ch...@wanadoo.fr> wrote:
>
> Hi,
>
> The SO_REUSEPORT patch has been in trunk for a few months now and has been proposed for backport in 2.4.x.
>
> Here is an interesting paper which gives a clear explanation and some benchmark results:
> http://www.intel.ie/content/dam/www/public/us/en/documents/white-papers/scaling-apache-server-performance-paper.pdf
>
>
> Would be great if it could be committed in 2.4.x.
> Having it reviewed and tested for 2.4.13 may not be possible because of the T&R window which seems to be in the coming days/weeks.
> (this already what was answered for the 2.4.11/2.4.12 release)
>
>
> Maybe, 2.4.14 could focus on reviewing/merging this patch and associated performance improvement?
> To help adoption, maybe an ASF server could be upgraded with a SO_REUSEPORT patched version of Apache to have our own measurements and see how it scales in a real world application.
> This has already been done in the past (testing impact of the skiplist implementation).
>
> Best regards,
> CJ
>
RE: SO_REUSEPORT
Posted by "Lu, Yingqi" <yi...@intel.com>.
Thank you very much for your help, Yann!
All, please test the patch and vote for us if you like it :-)
Thanks,
Yingqi
-----Original Message-----
From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
Sent: Thursday, May 14, 2015 4:45 PM
To: httpd
Subject: Re: SO_REUSEPORT
Hi Yingqi,
2 votes already (on 3), it makes its way ;)
Regards,
Yann.
On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi <yi...@intel.com> wrote:
> Hi All,
>
> I just want to check if anyone gets chances to check the SO_REUSEPORT patch? Any feedback?
>
> Thanks,
> Yingqi
>
> -----Original Message-----
> From: Lu, Yingqi [mailto:yingqi.lu@intel.com]
> Sent: Friday, May 08, 2015 8:58 AM
> To: dev@httpd.apache.org
> Subject: RE: SO_REUSEPORT
>
> Hi Christophe, Jim and Yann,
>
> Thank you very much for your consideration of putting SO_REUSEPORT patch in the 2.4 stable release.
>
> I am also very happy that you find the white paper :-) All the most recent testing results are included in the white paper. Also, we have tested the (graceful) restart on the patch (previously, there was a bug.), it should be fine now. Please test it to confirm.
>
> Please let me know if you need anything else. Your help is appreciated.
>
> Thanks,
> Yingqi
>
> -----Original Message-----
> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
> Sent: Friday, May 08, 2015 5:02 AM
> To: httpd
> Subject: Re: SO_REUSEPORT
>
> On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <ch...@wanadoo.fr> wrote:
>>
>> Maybe, 2.4.14 could focus on reviewing/merging this patch and
>> associated performance improvement?
>> To help adoption, maybe an ASF server could be upgraded with a
>> SO_REUSEPORT patched version of Apache to have our own measurements
>> and see how it scales in a real world application.
>
> I did some testing with an injector at the time of the proposal (on a 2.2.x version of the patch, so mainly with worker), and can confirm that it really scales much better.
> Where httpd without SO_REUSEPORT stops accepting/handling connections, it continues to shine with the option/buckets enabled.
> (I don't have the numbers for now, need to search deeper, btw the ones
> from Intel are probably more of interest...)
>
> So regarding the upgrade on infra, the difference may not be obvious if the tested machine is not "at the limits".
>
> One thing that probably is worth testing is (graceful) restarts, though.
>
> Regards,
> Yann.
Re: SO_REUSEPORT
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jun 5, 2015 at 5:11 PM, Eric Covener <co...@gmail.com> wrote:
> I'm trying to review & understand how this affects process management for
> things like MinSpareThreads/MaxSpareThreads e.g.
>
> - else if (idle_thread_count < min_spare_threads) {
> + else if (idle_thread_count < min_spare_threads / num_buckets) {
> /* terminate the free list */
> if (free_length == 0) { /* scoreboard is f
>
> - if (idle_thread_count > max_spare_threads) {
> + if (idle_thread_count > max_spare_threads / num_buckets) {
> /* Kill off one child */
>
> If I wanted between 100 and 200 spare threads available to do some slow
> stuff like proxy or CGI, would we really scale it back by the # of buckets
> or am I misunderstanding?
perform_idle_server_maintenance() is now called for each bucket in the
main loop, so this won't change the number of threads maintained per
loop.
Re: SO_REUSEPORT
Posted by Eric Covener <co...@gmail.com>.
I'm trying to review & understand how this affects process management for
things like MinSpareThreads/MaxSpareThreads e.g.
- else if (idle_thread_count < min_spare_threads) {
+ else if (idle_thread_count < min_spare_threads / num_buckets) {
/* terminate the free list */
if (free_length == 0) { /* scoreboard is f
- if (idle_thread_count > max_spare_threads) {
+ if (idle_thread_count > max_spare_threads / num_buckets) {
/* Kill off one child */
If I wanted between 100 and 200 spare threads available to do some slow
stuff like proxy or CGI, would we really scale it back by the # of buckets
or am I misunderstanding?
On Sun, May 17, 2015 at 4:31 PM Lu, Yingqi <yi...@intel.com> wrote:
> Hi Yann,
>
> Thank you very much for your help!
>
> Yingqi
>
> -----Original Message-----
> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
> Sent: Saturday, May 16, 2015 3:37 AM
> To: httpd
> Subject: Re: SO_REUSEPORT
>
> On Fri, May 15, 2015 at 5:12 PM, Jeff Trawick <tr...@gmail.com> wrote:
> > On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr <wrowe@rowe-clan.net
> >
> > wrote:
> >>
> >> My chief concern was that the phrase "Common Log" has a specific meaning
> >> to us.
> >>
> >> ap_mpm_common_log_startup() or something else descriptive would be a
> >> better name, but our crew is famous for not being terrific namers of
> things
> >> :)
> >>
> >> Did this compile with no warnings? It seems statics were used without
> >> being explicitly initialized, and I don't have my copy of K&R to check
> that
> >> these are always NULL, but guessing that's so.
> >
> >
> > yes; but ISTR that NetWare is the reason for explicit initialization in
> some
> > of our multi-platform code; I dunno the rhyme
>
> s/ap_log_common/ap_log_mpm_common/ in r1679714 and added to backport
> proposal.
>
> Regarding globals/statics explicit initializations (implicit
> initialization to {0} is required by the C standard), I don't think it
> is necessary/suitable since and it may move these variables from the
> .bss to the .data section, the former being quicker to initialize (as
> a whole) at load time (though explicit initializations to {0} usually
> go to .bss too but it depends on the compiler and/or flags, and we
> don't explicitely need .data for those).
> So I did not change the code wrt this...
>
RE: SO_REUSEPORT
Posted by "Lu, Yingqi" <yi...@intel.com>.
Hi Yann,
Thank you very much for your help!
Yingqi
-----Original Message-----
From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
Sent: Saturday, May 16, 2015 3:37 AM
To: httpd
Subject: Re: SO_REUSEPORT
On Fri, May 15, 2015 at 5:12 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>>
>> My chief concern was that the phrase "Common Log" has a specific meaning
>> to us.
>>
>> ap_mpm_common_log_startup() or something else descriptive would be a
>> better name, but our crew is famous for not being terrific namers of things
>> :)
>>
>> Did this compile with no warnings? It seems statics were used without
>> being explicitly initialized, and I don't have my copy of K&R to check that
>> these are always NULL, but guessing that's so.
>
>
> yes; but ISTR that NetWare is the reason for explicit initialization in some
> of our multi-platform code; I dunno the rhyme
s/ap_log_common/ap_log_mpm_common/ in r1679714 and added to backport proposal.
Regarding globals/statics explicit initializations (implicit
initialization to {0} is required by the C standard), I don't think it
is necessary/suitable since and it may move these variables from the
.bss to the .data section, the former being quicker to initialize (as
a whole) at load time (though explicit initializations to {0} usually
go to .bss too but it depends on the compiler and/or flags, and we
don't explicitely need .data for those).
So I did not change the code wrt this...
Re: SO_REUSEPORT
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, May 15, 2015 at 5:12 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>>
>> My chief concern was that the phrase "Common Log" has a specific meaning
>> to us.
>>
>> ap_mpm_common_log_startup() or something else descriptive would be a
>> better name, but our crew is famous for not being terrific namers of things
>> :)
>>
>> Did this compile with no warnings? It seems statics were used without
>> being explicitly initialized, and I don't have my copy of K&R to check that
>> these are always NULL, but guessing that's so.
>
>
> yes; but ISTR that NetWare is the reason for explicit initialization in some
> of our multi-platform code; I dunno the rhyme
s/ap_log_common/ap_log_mpm_common/ in r1679714 and added to backport proposal.
Regarding globals/statics explicit initializations (implicit
initialization to {0} is required by the C standard), I don't think it
is necessary/suitable since and it may move these variables from the
.bss to the .data section, the former being quicker to initialize (as
a whole) at load time (though explicit initializations to {0} usually
go to .bss too but it depends on the compiler and/or flags, and we
don't explicitely need .data for those).
So I did not change the code wrt this...
Re: SO_REUSEPORT
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> My chief concern was that the phrase "Common Log" has a specific meaning
> to us.
>
> ap_mpm_common_log_startup() or something else descriptive would be a
> better name, but our crew is famous for not being terrific namers of things
> :)
>
> Did this compile with no warnings? It seems statics were used without
> being explicitly initialized, and I don't have my copy of K&R to check that
> these are always NULL, but guessing that's so.
>
yes; but ISTR that NetWare is the reason for explicit initialization in
some of our multi-platform code; I dunno the rhyme
> For clarity alone, I'd prefer these were initialized like every other
> example they were adjacent to.
>
>
>
>
> On Fri, May 15, 2015 at 7:06 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> We are very close... I believe wrowe has some somewhat trivial
>> reservations about it, but we are awaiting 1 more vote.
>>
>> Someone want to address wrowes concerns on trunk and patch
>> the patch (stuff like naming)? I may have time next week.
>>
>> > On May 14, 2015, at 7:45 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> >
>> > Hi Yingqi,
>> >
>> > 2 votes already (on 3), it makes its way ;)
>> >
>> > Regards,
>> > Yann.
>> >
>> >
>> > On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi <yi...@intel.com>
>> wrote:
>> >> Hi All,
>> >>
>> >> I just want to check if anyone gets chances to check the SO_REUSEPORT
>> patch? Any feedback?
>> >>
>> >> Thanks,
>> >> Yingqi
>> >>
>> >> -----Original Message-----
>> >> From: Lu, Yingqi [mailto:yingqi.lu@intel.com]
>> >> Sent: Friday, May 08, 2015 8:58 AM
>> >> To: dev@httpd.apache.org
>> >> Subject: RE: SO_REUSEPORT
>> >>
>> >> Hi Christophe, Jim and Yann,
>> >>
>> >> Thank you very much for your consideration of putting SO_REUSEPORT
>> patch in the 2.4 stable release.
>> >>
>> >> I am also very happy that you find the white paper :-) All the most
>> recent testing results are included in the white paper. Also, we have
>> tested the (graceful) restart on the patch (previously, there was a bug.),
>> it should be fine now. Please test it to confirm.
>> >>
>> >> Please let me know if you need anything else. Your help is appreciated.
>> >>
>> >> Thanks,
>> >> Yingqi
>> >>
>> >> -----Original Message-----
>> >> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
>> >> Sent: Friday, May 08, 2015 5:02 AM
>> >> To: httpd
>> >> Subject: Re: SO_REUSEPORT
>> >>
>> >> On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <
>> christophe.jaillet@wanadoo.fr> wrote:
>> >>>
>> >>> Maybe, 2.4.14 could focus on reviewing/merging this patch and
>> >>> associated performance improvement?
>> >>> To help adoption, maybe an ASF server could be upgraded with a
>> >>> SO_REUSEPORT patched version of Apache to have our own measurements
>> >>> and see how it scales in a real world application.
>> >>
>> >> I did some testing with an injector at the time of the proposal (on a
>> 2.2.x version of the patch, so mainly with worker), and can confirm that it
>> really scales much better.
>> >> Where httpd without SO_REUSEPORT stops accepting/handling connections,
>> it continues to shine with the option/buckets enabled.
>> >> (I don't have the numbers for now, need to search deeper, btw the ones
>> from Intel are probably more of interest...)
>> >>
>> >> So regarding the upgrade on infra, the difference may not be obvious
>> if the tested machine is not "at the limits".
>> >>
>> >> One thing that probably is worth testing is (graceful) restarts,
>> though.
>> >>
>> >> Regards,
>> >> Yann.
>>
>>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: SO_REUSEPORT
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
My chief concern was that the phrase "Common Log" has a specific meaning to
us.
ap_mpm_common_log_startup() or something else descriptive would be a better
name, but our crew is famous for not being terrific namers of things :)
Did this compile with no warnings? It seems statics were used without
being explicitly initialized, and I don't have my copy of K&R to check that
these are always NULL, but guessing that's so. For clarity alone, I'd
prefer these were initialized like every other example they were adjacent
to.
On Fri, May 15, 2015 at 7:06 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> We are very close... I believe wrowe has some somewhat trivial
> reservations about it, but we are awaiting 1 more vote.
>
> Someone want to address wrowes concerns on trunk and patch
> the patch (stuff like naming)? I may have time next week.
>
> > On May 14, 2015, at 7:45 PM, Yann Ylavic <yl...@gmail.com> wrote:
> >
> > Hi Yingqi,
> >
> > 2 votes already (on 3), it makes its way ;)
> >
> > Regards,
> > Yann.
> >
> >
> > On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi <yi...@intel.com> wrote:
> >> Hi All,
> >>
> >> I just want to check if anyone gets chances to check the SO_REUSEPORT
> patch? Any feedback?
> >>
> >> Thanks,
> >> Yingqi
> >>
> >> -----Original Message-----
> >> From: Lu, Yingqi [mailto:yingqi.lu@intel.com]
> >> Sent: Friday, May 08, 2015 8:58 AM
> >> To: dev@httpd.apache.org
> >> Subject: RE: SO_REUSEPORT
> >>
> >> Hi Christophe, Jim and Yann,
> >>
> >> Thank you very much for your consideration of putting SO_REUSEPORT
> patch in the 2.4 stable release.
> >>
> >> I am also very happy that you find the white paper :-) All the most
> recent testing results are included in the white paper. Also, we have
> tested the (graceful) restart on the patch (previously, there was a bug.),
> it should be fine now. Please test it to confirm.
> >>
> >> Please let me know if you need anything else. Your help is appreciated.
> >>
> >> Thanks,
> >> Yingqi
> >>
> >> -----Original Message-----
> >> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
> >> Sent: Friday, May 08, 2015 5:02 AM
> >> To: httpd
> >> Subject: Re: SO_REUSEPORT
> >>
> >> On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <
> christophe.jaillet@wanadoo.fr> wrote:
> >>>
> >>> Maybe, 2.4.14 could focus on reviewing/merging this patch and
> >>> associated performance improvement?
> >>> To help adoption, maybe an ASF server could be upgraded with a
> >>> SO_REUSEPORT patched version of Apache to have our own measurements
> >>> and see how it scales in a real world application.
> >>
> >> I did some testing with an injector at the time of the proposal (on a
> 2.2.x version of the patch, so mainly with worker), and can confirm that it
> really scales much better.
> >> Where httpd without SO_REUSEPORT stops accepting/handling connections,
> it continues to shine with the option/buckets enabled.
> >> (I don't have the numbers for now, need to search deeper, btw the ones
> from Intel are probably more of interest...)
> >>
> >> So regarding the upgrade on infra, the difference may not be obvious if
> the tested machine is not "at the limits".
> >>
> >> One thing that probably is worth testing is (graceful) restarts, though.
> >>
> >> Regards,
> >> Yann.
>
>
Re: SO_REUSEPORT
Posted by Jim Jagielski <ji...@jaguNET.com>.
We are very close... I believe wrowe has some somewhat trivial
reservations about it, but we are awaiting 1 more vote.
Someone want to address wrowes concerns on trunk and patch
the patch (stuff like naming)? I may have time next week.
> On May 14, 2015, at 7:45 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> Hi Yingqi,
>
> 2 votes already (on 3), it makes its way ;)
>
> Regards,
> Yann.
>
>
> On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi <yi...@intel.com> wrote:
>> Hi All,
>>
>> I just want to check if anyone gets chances to check the SO_REUSEPORT patch? Any feedback?
>>
>> Thanks,
>> Yingqi
>>
>> -----Original Message-----
>> From: Lu, Yingqi [mailto:yingqi.lu@intel.com]
>> Sent: Friday, May 08, 2015 8:58 AM
>> To: dev@httpd.apache.org
>> Subject: RE: SO_REUSEPORT
>>
>> Hi Christophe, Jim and Yann,
>>
>> Thank you very much for your consideration of putting SO_REUSEPORT patch in the 2.4 stable release.
>>
>> I am also very happy that you find the white paper :-) All the most recent testing results are included in the white paper. Also, we have tested the (graceful) restart on the patch (previously, there was a bug.), it should be fine now. Please test it to confirm.
>>
>> Please let me know if you need anything else. Your help is appreciated.
>>
>> Thanks,
>> Yingqi
>>
>> -----Original Message-----
>> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
>> Sent: Friday, May 08, 2015 5:02 AM
>> To: httpd
>> Subject: Re: SO_REUSEPORT
>>
>> On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <ch...@wanadoo.fr> wrote:
>>>
>>> Maybe, 2.4.14 could focus on reviewing/merging this patch and
>>> associated performance improvement?
>>> To help adoption, maybe an ASF server could be upgraded with a
>>> SO_REUSEPORT patched version of Apache to have our own measurements
>>> and see how it scales in a real world application.
>>
>> I did some testing with an injector at the time of the proposal (on a 2.2.x version of the patch, so mainly with worker), and can confirm that it really scales much better.
>> Where httpd without SO_REUSEPORT stops accepting/handling connections, it continues to shine with the option/buckets enabled.
>> (I don't have the numbers for now, need to search deeper, btw the ones from Intel are probably more of interest...)
>>
>> So regarding the upgrade on infra, the difference may not be obvious if the tested machine is not "at the limits".
>>
>> One thing that probably is worth testing is (graceful) restarts, though.
>>
>> Regards,
>> Yann.
Re: SO_REUSEPORT
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Yingqi,
2 votes already (on 3), it makes its way ;)
Regards,
Yann.
On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi <yi...@intel.com> wrote:
> Hi All,
>
> I just want to check if anyone gets chances to check the SO_REUSEPORT patch? Any feedback?
>
> Thanks,
> Yingqi
>
> -----Original Message-----
> From: Lu, Yingqi [mailto:yingqi.lu@intel.com]
> Sent: Friday, May 08, 2015 8:58 AM
> To: dev@httpd.apache.org
> Subject: RE: SO_REUSEPORT
>
> Hi Christophe, Jim and Yann,
>
> Thank you very much for your consideration of putting SO_REUSEPORT patch in the 2.4 stable release.
>
> I am also very happy that you find the white paper :-) All the most recent testing results are included in the white paper. Also, we have tested the (graceful) restart on the patch (previously, there was a bug.), it should be fine now. Please test it to confirm.
>
> Please let me know if you need anything else. Your help is appreciated.
>
> Thanks,
> Yingqi
>
> -----Original Message-----
> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
> Sent: Friday, May 08, 2015 5:02 AM
> To: httpd
> Subject: Re: SO_REUSEPORT
>
> On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <ch...@wanadoo.fr> wrote:
>>
>> Maybe, 2.4.14 could focus on reviewing/merging this patch and
>> associated performance improvement?
>> To help adoption, maybe an ASF server could be upgraded with a
>> SO_REUSEPORT patched version of Apache to have our own measurements
>> and see how it scales in a real world application.
>
> I did some testing with an injector at the time of the proposal (on a 2.2.x version of the patch, so mainly with worker), and can confirm that it really scales much better.
> Where httpd without SO_REUSEPORT stops accepting/handling connections, it continues to shine with the option/buckets enabled.
> (I don't have the numbers for now, need to search deeper, btw the ones from Intel are probably more of interest...)
>
> So regarding the upgrade on infra, the difference may not be obvious if the tested machine is not "at the limits".
>
> One thing that probably is worth testing is (graceful) restarts, though.
>
> Regards,
> Yann.
RE: SO_REUSEPORT
Posted by "Lu, Yingqi" <yi...@intel.com>.
Hi All,
I just want to check if anyone gets chances to check the SO_REUSEPORT patch? Any feedback?
Thanks,
Yingqi
-----Original Message-----
From: Lu, Yingqi [mailto:yingqi.lu@intel.com]
Sent: Friday, May 08, 2015 8:58 AM
To: dev@httpd.apache.org
Subject: RE: SO_REUSEPORT
Hi Christophe, Jim and Yann,
Thank you very much for your consideration of putting SO_REUSEPORT patch in the 2.4 stable release.
I am also very happy that you find the white paper :-) All the most recent testing results are included in the white paper. Also, we have tested the (graceful) restart on the patch (previously, there was a bug.), it should be fine now. Please test it to confirm.
Please let me know if you need anything else. Your help is appreciated.
Thanks,
Yingqi
-----Original Message-----
From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
Sent: Friday, May 08, 2015 5:02 AM
To: httpd
Subject: Re: SO_REUSEPORT
On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <ch...@wanadoo.fr> wrote:
>
> Maybe, 2.4.14 could focus on reviewing/merging this patch and
> associated performance improvement?
> To help adoption, maybe an ASF server could be upgraded with a
> SO_REUSEPORT patched version of Apache to have our own measurements
> and see how it scales in a real world application.
I did some testing with an injector at the time of the proposal (on a 2.2.x version of the patch, so mainly with worker), and can confirm that it really scales much better.
Where httpd without SO_REUSEPORT stops accepting/handling connections, it continues to shine with the option/buckets enabled.
(I don't have the numbers for now, need to search deeper, btw the ones from Intel are probably more of interest...)
So regarding the upgrade on infra, the difference may not be obvious if the tested machine is not "at the limits".
One thing that probably is worth testing is (graceful) restarts, though.
Regards,
Yann.
RE: SO_REUSEPORT
Posted by "Lu, Yingqi" <yi...@intel.com>.
Hi Christophe, Jim and Yann,
Thank you very much for your consideration of putting SO_REUSEPORT patch in the 2.4 stable release.
I am also very happy that you find the white paper :-) All the most recent testing results are included in the white paper. Also, we have tested the (graceful) restart on the patch (previously, there was a bug.), it should be fine now. Please test it to confirm.
Please let me know if you need anything else. Your help is appreciated.
Thanks,
Yingqi
-----Original Message-----
From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
Sent: Friday, May 08, 2015 5:02 AM
To: httpd
Subject: Re: SO_REUSEPORT
On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET <ch...@wanadoo.fr> wrote:
>
> Maybe, 2.4.14 could focus on reviewing/merging this patch and
> associated performance improvement?
> To help adoption, maybe an ASF server could be upgraded with a
> SO_REUSEPORT patched version of Apache to have our own measurements
> and see how it scales in a real world application.
I did some testing with an injector at the time of the proposal (on a 2.2.x version of the patch, so mainly with worker), and can confirm that it really scales much better.
Where httpd without SO_REUSEPORT stops accepting/handling connections, it continues to shine with the option/buckets enabled.
(I don't have the numbers for now, need to search deeper, btw the ones from Intel are probably more of interest...)
So regarding the upgrade on infra, the difference may not be obvious if the tested machine is not "at the limits".
One thing that probably is worth testing is (graceful) restarts, though.
Regards,
Yann.
Re: SO_REUSEPORT
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET
<ch...@wanadoo.fr> wrote:
>
> Maybe, 2.4.14 could focus on reviewing/merging this patch and associated
> performance improvement?
> To help adoption, maybe an ASF server could be upgraded with a SO_REUSEPORT
> patched version of Apache to have our own measurements and see how it scales
> in a real world application.
I did some testing with an injector at the time of the proposal (on a
2.2.x version of the patch, so mainly with worker), and can confirm
that it really scales much better.
Where httpd without SO_REUSEPORT stops accepting/handling connections,
it continues to shine with the option/buckets enabled.
(I don't have the numbers for now, need to search deeper, btw the ones
from Intel are probably more of interest...)
So regarding the upgrade on infra, the difference may not be obvious
if the tested machine is not "at the limits".
One thing that probably is worth testing is (graceful) restarts, though.
Regards,
Yann.