Re: SO_REUSEPORT
On Fri, Jun 5, 2015 at 5:11 PM, Eric Covener 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
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 wrote:
> Hi Yann,
>
> Thank you very much for your help!
>
> Yingqi
>
> -Original Message-
> From: Yann Ylavic [mailto:[email protected]]
> 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 wrote:
> > On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr >
> > 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
Hi Yann, Thank you very much for your help! Yingqi -Original Message- From: Yann Ylavic [mailto:[email protected]] 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 wrote: > On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr > 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
On Fri, May 15, 2015 at 5:12 PM, Jeff Trawick wrote:
> On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr
> 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
On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr 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 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 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 >> 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:[email protected]] >> >> Sent: Friday, May 08, 2015 8:58 AM >> >> To: [email protected] >> >> 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:[email protected]] >> >> 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 < >> [email protected]> 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
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 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 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 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:[email protected]] > >> Sent: Friday, May 08, 2015 8:58 AM > >> To: [email protected] > >> 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:[email protected]] > >> 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 < > [email protected]> 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
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 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 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:[email protected]] >> Sent: Friday, May 08, 2015 8:58 AM >> To: [email protected] >> 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:[email protected]] >> 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 >> 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
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:[email protected]] 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 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:[email protected]] > Sent: Friday, May 08, 2015 8:58 AM > To: [email protected] > 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:[email protected]] > 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 > 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
Hi Yingqi, 2 votes already (on 3), it makes its way ;) Regards, Yann. On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi 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:[email protected]] > Sent: Friday, May 08, 2015 8:58 AM > To: [email protected] > 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:[email protected]] > 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 > 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
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:[email protected]] Sent: Friday, May 08, 2015 8:58 AM To: [email protected] 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:[email protected]] 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 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
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:[email protected]] 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 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
On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET 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
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 > 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 in the children processes
Hi Yann, As we pointed out in our original discussion thread, we dropped the child process implementation due to the kernel defect with changing the number of open sockets. Now, we quickly tested this child process implementation (prefork) with our workload on a modern Xeon dual sockets server and most recent 3.13.6 kernel again. 1. We do not see "connection reset" errors during the run (ramp up and steady stay) any more. However, we noticed that our workload cannot ramp down and terminate on its own with this child process implementation. This never happened before with either "out of box" httpd or the parent process implementation. After manually force shutdown the workload, we saw these "connection reset" errors again. 2. During the run, we noticed that there are tons of "read timed out" errors. These errors not only happen when the system is highly utilized, it even happens when system is only 10% utilized. The response time was high. 3. Compared to parent process implementation, we found child process implementation results in significantly higher (up to 10X) response time (The read timed out errors are not counted in the result) at different CPU utilization levels. At peak performance level, it has ~22% less throughput with tons of "connection reset" errors in additional to "read timed out" errors. Parent process implementation does not have errors. We think the reason of above findings may be caused by: 1. Too many open sockets created by the children processes; and/or 2. Parent process does not have control, or maybe 3. Kernel defect is not fully addressed. On the other hand, the parent implementation keeps minimal number of open sockets that takes advantage of SO_REUSEPORT and keeps the environment more controllable. We are currently modifying the code based on all the feedbacks from the community with the original parent process implementation which also includes separating the original patch between with and without SO_REUSEPORT support. This would make SO_REUSEPORT patch cleaner and simpler. Thanks, Yingqi (people at work also call me Lucy:)) From: Yann Ylavic [mailto:[email protected]] Sent: Friday, March 07, 2014 9:07 AM To: httpd Subject: SO_REUSEPORT in the children processes Hi all, the patch about SO_REUSEPORT proposed by Yingqi Lu in [1] and discussed in [2] uses listeners buckets to address a defect [3] in the current linux implementation (his patch goes beyond SO_REUSEPORT though, and suggests a new MPM even when the option is not available). Should this defect be addressed by linux folks, the event/worker/prefork MPMs could take full advantage of the option (linux-3.9+) with quite simple modifications of the current code. I'm proposing here the corresponding patch. The idea is to re-create and re-bind/listen the parent's listeners sockets for each child process, when starting, before dropping priviledges. For this, the patch introduces a new ap_reopen_listeners() function (meant to be called by each child) to do the job on the inherited listeners. It does nothing unless HAVE_SO_REUSEPORT is defined. The advantage of this approach is that no accept mutex is needed anymore (each child has its own sockets), hence the SAFE_ACCEPT macros can do nothing when HAVE_SO_REUSEPORT is defined. The new (incoming) connections are evenly distributed accross the children for all the listners (as assured by Linux when SO_REUSEPORT is used). I'm proposing the patch here so that everyone can figure out whether SO_REUSEPORT per se needs its own MPM or not (once/if the defect is fixed). The option seems to be quite easily pluggable to existing MPMs (no ABI change), and I don't see an advantage to not using it when available (and working). Also, FreeBSD has an implementation of SO_REUSEPORT, however I couldn't find whether it has the same scheduling garantee or not (at least I guess the accept mutex can be avoided too). Regarding the linux kernel defect, is someone aware of a fix/work on that in the latest versions? Finally, about the accept mutex, mpm event seems to work well without any, why prefork and worker would need one (both poll() all the listeners in a single thread, while other children can do the same)? The patch follows and is attached. It can already be tested with a workaround against the defect: don't let perform_idle_server_maintenance() create/stop children after startup (eg. StartServers, ServerLimit, Min/MaxSpareServers using the same value). Thoughts, feedbacks welcome. Regards, Yann. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55897#c7 [2] http://mail-archives.apache.org/mod_mbox/httpd-bugs/201312.mbox/%[email protected]/bugzilla/%3E [3] http://lwn.net/Articles/542629/ and http://lwn.net/Articles/542738/ Index: server/mpm/event/event.c === --- server/mpm/event/event.c(revision 1575322) +++ server/mpm/event/event.c(wor
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
the next one with his vendetta i just *asked* consider post plain text nothing more Am 10.03.2014 00:32, schrieb Nick Edwards: > Truer words were never spoken about Harald Reindl, this person brings > trouble to every mailing list he joins > > postfix - banned read the history > fedora - moderation no longer true for good reasons > centos - moderation/banned because *one* posting years ago > roundcube - moderation caused by Noel Butler and nobody else > dovecot - final warnings in a thread flamed by Noel Butler and youself interesing that i am still there, Noel not and he had his vendetta against Timo long ago > I do not find his hostname in bl.alt-backspace.org because it was removed months ago after even Noel Butler realized that it is the wrong way to blacklist whole networks because personal problems with a single person and if people like Noel and you just shut up many problems you list abvoe simply would not exist __ frankly who do you and Noel think that you are to rule the world? did i do anyhting bad on this list? if yes show me if no just shut up with your persnal justice trying to rule the world there is not much left to say than that reject message below : host mail.ausics.net[27.33.160.23] said: 554 5.7.1 Sender address rejected: faggots not allowed signature.asc Description: OpenPGP digital signature
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
Truer words were never spoken about Harald Reindl, this person brings trouble to every mailing list he joins postfix - banned fedora - moderation centos - moderation/banned roundcube - moderation dovecot - final warnings and they are just the lists I know of, and when moderated he is known to send direct abuse and threats to people (this is why on roundcube he will never be post status again) removing the content of such deserved vulgar (about time somebody gave him a dose of his own medicine for once) I do not find his hostname in bl.alt-backspace.org so, if thats a fabrication, well, I'll leave it to your imaginations. I suggest this list moderates him as well else this is just the start of things to come going by his very poor track record. Most people (myself included) have him filtered out anyway- now he's found his way onto this list, I no longer whitelist this list.
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
On Sun, Mar 9, 2014 at 2:01 PM, Reindl Harald wrote: > > Am 08.03.2014 01:38, schrieb Noel Butler: >> This will be dealt with off list > > with the words below which are only a part of the off-list reply It should be kept off-list. Just stop.
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
Am 08.03.2014 01:38, schrieb Noel Butler: > This will be dealt with off list with the words below which are only a part of the off-list reply and this person is allowed to maintain a RBL in australia and so anybody using "bl.alt-backspace.org" should re-consider that Noel Butler: >> listen you cock sucking little fucking faggot cunt, fuclk off with your >> fucking >> hollier than though fucking shit ok cuntface you are a nobody on any list >> depsite >> the fact you think you are, you have no fucknig right to ask anyone to type >> the >> way you want ok cunt eyes, just fuck off and spew your fucking shit is a psychopathic reaction to the the simple question post in plaintext and was the direct repsone to that off-list reply to Noel > On 08/03/2014 10:49, Reindl Harald wrote: >>> if you fail to heed that warning your the only one who will regret it >> stop your personal vendetta - the only one playing internet cop is you >> >> i have asked in a nice way to not post HTML and explained why >> the other person had no problem with my question / hin > Original-Nachricht > Betreff: Re: SO_REUSEPORT in the children processes > Datum: Fri, 07 Mar 2014 18:24:26 +0100 > Von: Reindl Harald > Antwort an: [email protected] > An: [email protected] > > Am 07.03.2014 18:07, schrieb Yann Ylavic > > can you please post plaintext instead HTML to lists > > for me such messages are unreadable after medical operations > on both eyes because you override my MUA font settings > On 08/03/2014 09:51, Reindl Harald wrote: > >> what exactly is your personal problem? >>>> can you please post plaintext instead HTML to lists >> you did see the word "please"? >>>> for me such messages are unreadable after medical operations on both eyes >>>> because you override my MUA font settings >> you understood that reason? >> >> i follow that thread longer honestly interested >> there where a few HTML respones and *all* oft hem left unread >> because they contained a lot of content >>>> he has been warned about playing net cop >> who do you think you are calling others net cop because they ask for >> easier readable posts while you are the one proven to playing net cop >> due maintaining a RBL? >>>> Is it written anywhere in the bylaws of this mailing list >> is the response you should have been attacking >> >> Am 08.03.2014 00:39, schrieb Noel Butler: >>> Harry, you have been warned before, dont bring your antics onto this list, >>> this is about the only list you have >>> been most well behaved on, unlike others, please remember our previous >>> conversations. If you think a posters >>> post violates some RFC, ignore it, or take it up with him in private, do >>> not pollute this list with your >>> bullshit. Thank you :) On Fri, 2014-03-07 at 19:13 +0100, Reindl Harald >>> wrote: >>>> Am 07.03.2014 18:58, schrieb Mikhail T.: >>>>> On 07.03.2014 12:28, Yann Ylavic wrote: >>>>>> Sorry, this was posted from gmail... >>>>> Is it written anywhere in the bylaws of this mailing list that use of >>>>> HTML is something to apologize for? >>>> nearly any mailing-list has it written clear, some even reject HTML and on >>>> some others you get warned by the >>>> owner (postfix as example) >>>> https://www.google.com/search?q=mailing+list+etiquette+plaintext+only >>>> https://www.google.at/search?q=mailing+list+etiquette+no+html >>>> _ >>>> http://www.apache.org/foundation/mailinglists.htmlNote: Spam filters don't >>>> like messages with empty Subjects; >>>> just use e.g. "subscribe" or "unsubscribe". Spam filters are also more >>>> likely to reject HTML-formatted >>>> messages; please use plain text >>>>> With all due sympathies to Reindl's medical condition, why must we -- in >>>>> the second decade of the 21st century >>>>> -- deny ourselves the means of expression afforded by HTML on this list? >>>> because the message had no single HTML formatting and was written in plain >>>> but as HTML may be a godd reason it >>>> hardly makes sense to write email in HTML, they just explode after some >>>> replies/quotes and forwardings with >>>> different clients while a conversation in plaintext survises thousands of >>>> replies without lose a sane quoting signature.asc Description: OpenPGP digital signature
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
This will be dealt with off list On 08/03/2014 09:51, Reindl Harald wrote: > what exactly is your personal problem? > can you please post plaintext instead HTML to lists you did see the word "please"? >> for me such messages are unreadable after medical operations on both eyes >> because you override my MUA font settings you understood that reason? i follow that thread longer honestly interested there where a few HTML respones and *all* oft hem left unread because they contained a lot of content >> he has been warned about playing net cop who do you think you are calling others net cop because they ask for easier readable posts while you are the one proven to playing net cop due maintaining a RBL? >> Is it written anywhere in the bylaws of this mailing list is the response you should have been attacking Am 08.03.2014 00:39, schrieb Noel Butler: > Harry, you have been warned before, dont bring your antics onto this list, > this is about the only list you have been most well behaved on, unlike > others, please remember our previous conversations. If you think a posters > post violates some RFC, ignore it, or take it up with him in private, do not > pollute this list with your bullshit. Thank you :) On Fri, 2014-03-07 at > 19:13 +0100, Reindl Harald wrote: Am 07.03.2014 18:58, schrieb Mikhail T.: On > 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is > it written anywhere in the bylaws of this mailing list that use of HTML is > something to apologize for? nearly any mailing-list has it written clear, some even reject HTML and on some others you get warned by the owner (postfix as example) https://www.google.com/search?q=mailing+list+etiquette+plaintext+only [1] https://www.google.at/search?q=mailing+list+etiquette+no+html [2] _ http://www.apache.org/foundation/mailinglists.html [3]Note: Spam filters don't like messages with empty Subjects; just use e.g. "subscribe" or "unsubscribe". Spam filters are also more likely to reject HTML-formatted messages; please use plain text > With all due sympathies to Reindl's medical condition, why must we -- in the > second decade of the 21st century -- deny ourselves the means of expression > afforded by HTML on this list? because the message had no single HTML formatting and was written in plain but as HTML may be a godd reason it hardly makes sense to write email in HTML, they just explode after some replies/quotes and forwardings with different clients while a conversation in plaintext survises thousands of replies without lose a sane quoting Links: -- [1] https://www.google.com/search?q=mailing+list+etiquette+plaintext+only [2] https://www.google.at/search?q=mailing+list+etiquette+no+html [3] http://www.apache.org/foundation/mailinglists.html
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
what exactly is your personal problem? >> can you please post plaintext instead HTML to lists you did see the word "please"? >> for me such messages are unreadable after medical operations >> on both eyes because you override my MUA font settings you understood that reason? i follow that thread longer honestly interested there where a few HTML respones and *all* oft hem left unread because they contained a lot of content >> he has been warned about playing net cop who do you think you are calling others net cop because they ask for easier readable posts while you are the one proven to playing net cop due maintaining a RBL? >> Is it written anywhere in the bylaws of this mailing list is the response you should have been attacking Am 08.03.2014 00:39, schrieb Noel Butler: > Harry, you have been warned before, dont bring your antics onto this list, > this is about the only list you have > been most well behaved on, unlike others, please remember our previous > conversations. If you think a posters post > violates some RFC, ignore it, or take it up with him in private, do not > pollute this list with your bullshit. > > Thank you :) > > On Fri, 2014-03-07 at 19:13 +0100, Reindl Harald wrote: >> Am 07.03.2014 18:58, schrieb Mikhail T.: >> > On 07.03.2014 12:28, Yann Ylavic wrote: >> >> Sorry, this was posted from gmail... >> > Is it written anywhere in the bylaws of this mailing list >> > that use of HTML is something to apologize for? >> >> nearly any mailing-list has it written clear, some even reject HTML >> and on some others you get warned by the owner (postfix as example) >> >> https://www.google.com/search?q=mailing+list+etiquette+plaintext+only >> https://www.google.at/search?q=mailing+list+etiquette+no+html >> _ >> >> http://www.apache.org/foundation/mailinglists.html >> >> Note: Spam filters don't like messages with empty Subjects; just use e.g. >> "subscribe" or "unsubscribe". Spam filters are also more likely to reject >> HTML-formatted messages; please use plain text >> >> > With all due sympathies to Reindl's medical condition, why must we -- >> > in the second decade of the 21st century -- deny ourselves the means >> > of expression afforded by HTML on this list? >> >> because the message had no single HTML formatting and >> was written in plain but as HTML may be a godd reason >> >> it hardly makes sense to write email in HTML, they just >> explode after some replies/quotes and forwardings with >> different clients while a conversation in plaintext >> survises thousands of replies without lose a sane quoting signature.asc Description: OpenPGP digital signature
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
Harry, you have been warned before, dont bring your antics onto this list, this is about the only list you have been most well behaved on, unlike others, please remember our previous conversations. If you think a posters post violates some RFC, ignore it, or take it up with him in private, do not pollute this list with your bullshit. Thank you :) On Fri, 2014-03-07 at 19:13 +0100, Reindl Harald wrote: > Am 07.03.2014 18:58, schrieb Mikhail T.: > > On 07.03.2014 12:28, Yann Ylavic wrote: > >> Sorry, this was posted from gmail... > > Is it written anywhere in the bylaws of this mailing list > > that use of HTML is something to apologize for? > > nearly any mailing-list has it written clear, some even reject HTML > and on some others you get warned by the owner (postfix as example) > > https://www.google.com/search?q=mailing+list+etiquette+plaintext+only > https://www.google.at/search?q=mailing+list+etiquette+no+html > _ > > http://www.apache.org/foundation/mailinglists.html > > Note: Spam filters don't like messages with empty Subjects; just use e.g. > "subscribe" or "unsubscribe". Spam filters are also more likely to reject > HTML-formatted messages; please use plain text > > > With all due sympathies to Reindl's medical condition, why must we -- > > in the second decade of the 21st century -- deny ourselves the means > > of expression afforded by HTML on this list? > > because the message had no single HTML formatting and > was written in plain but as HTML may be a godd reason > > it hardly makes sense to write email in HTML, they just > explode after some replies/quotes and forwardings with > different clients while a conversation in plaintext > survises thousands of replies without lose a sane quoting > <> signature.asc Description: This is a digitally signed message part
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
On Fri, 2014-03-07 at 12:58 -0500, Mikhail T. wrote: > On 07.03.2014 12:28, Yann Ylavic wrote: > > > > > Sorry, this was posted from gmail... > > Is it written anywhere in the bylaws of this mailing list, that use of > HTML is something to apologize for? With all due sympathies to > Reindl's medical Absolutely no apology required Harald is just a system admin subscribed to this http developer list, he has no association with Apache Software Foundation, he has been warned about playing net cop where he has no authority to do so before, ignore him. signature.asc Description: This is a digitally signed message part
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
Am 07.03.2014 18:58, schrieb Mikhail T.: > On 07.03.2014 12:28, Yann Ylavic wrote: >> Sorry, this was posted from gmail... > Is it written anywhere in the bylaws of this mailing list > that use of HTML is something to apologize for? nearly any mailing-list has it written clear, some even reject HTML and on some others you get warned by the owner (postfix as example) https://www.google.com/search?q=mailing+list+etiquette+plaintext+only https://www.google.at/search?q=mailing+list+etiquette+no+html _ http://www.apache.org/foundation/mailinglists.html Note: Spam filters don't like messages with empty Subjects; just use e.g. "subscribe" or "unsubscribe". Spam filters are also more likely to reject HTML-formatted messages; please use plain text > With all due sympathies to Reindl's medical condition, why must we -- > in the second decade of the 21st century -- deny ourselves the means > of expression afforded by HTML on this list? because the message had no single HTML formatting and was written in plain but as HTML may be a godd reason it hardly makes sense to write email in HTML, they just explode after some replies/quotes and forwardings with different clients while a conversation in plaintext survises thousands of replies without lose a sane quoting signature.asc Description: OpenPGP digital signature
Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
On 07.03.2014 12:28, Yann Ylavic wrote: > Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list, that use of HTML is something to apologize for? With all due sympathies to Reindl's medical condition, why must we -- in the second decade of the 21st century -- deny ourselves the means of expression afforded by HTML on this list? He can -- ought to be able to -- adjust his MUA to use his font-preferences over whatever may be specified in the incoming email. I'd ask this question on /any/ mailing list, but it seems especially ironic among developers of Apache httpd -- software meant to distribute content, that is most often written in HTML... Granted, some HTML can be offensive even to the healthy eyes -- and ought to be viewed as impolite (not that Yann's was anything of the kind). But to request, as Reindl did, that /all/ postings -- from all participants -- be in plain text, seems rather overbearing... > Here is the plain text. Wouldn't it be better to send such a duplication to Reindl /personally/? To avoid this becoming a list-wide flame war, I ask for the powers running this list to convene and hand us the law: either HTML is acceptable (my own preference), or it is not (in which case it should be bounced back by the mailing list software with an appropriate message). -mi
Re: SO_REUSEPORT in the children processes
On Fri, Mar 7, 2014 at 6:35 PM, Eric Covener wrote: >> Sorry, this was posted from gmail... > > FWIW I did not really see the distinctive HTML look and feel reading > it on gmail. I have none... and won't uncheck the "Plain text mode" anymore. Otherwise it's almost impossible to copy/paste without erratic result. It looks and feels a bit like it wants :p
Re: SO_REUSEPORT in the children processes
> Sorry, this was posted from gmail... FWIW I did not really see the distinctive HTML look and feel reading it on gmail.
Re: SO_REUSEPORT in the children processes
On Fri, Mar 7, 2014 at 6:24 PM, Reindl Harald wrote: > > > Am 07.03.2014 18:07, schrieb Yann Ylavic > > can you please post plaintext instead HTML to lists > > for me such messages are unreadable after medical operations > on both eyes because you override my MUA font settings > Sorry, this was posted from gmail... Here is the plain text. *** Hi all, the patch about SO_REUSEPORT proposed by Yingqi Lu in [1] and discussed in [2] uses listeners buckets to address a defect [3] in the current linux implementation (his patch goes beyond SO_REUSEPORT though, and suggests a new MPM even when the option is not available). Should this defect be addressed by linux folks, the event/worker/prefork MPMs could take full advantage of the option (linux-3.9+) with quite simple modifications of the current code. I'm proposing here the corresponding patch. The idea is to re-create and re-bind/listen the parent's listeners sockets for each child process, when starting, before dropping priviledges. For this, the patch introduces a new ap_reopen_listeners() function (meant to be called by each child) to do the job on the inherited listeners. It does nothing unless HAVE_SO_REUSEPORT is defined. The advantage of this approach is that no accept mutex is needed anymore (each child has its own sockets), hence the SAFE_ACCEPT macros can do nothing when HAVE_SO_REUSEPORT is defined. The new (incoming) connections are evenly distributed accross the children for all the listners (as assured by Linux when SO_REUSEPORT is used). I'm proposing the patch here so that everyone can figure out whether SO_REUSEPORT per se needs its own MPM or not (once/if the defect is fixed). The option seems to be quite easily pluggable to existing MPMs (no ABI change), and I don't see an advantage to not using it when available (and working). Also, FreeBSD has an implementation of SO_REUSEPORT, however I couldn't find whether it has the same scheduling garantee or not (at least I guess the accept mutex can be avoided too). Regarding the linux kernel defect, is someone aware of a fix/work on that in the latest versions? Finally, about the accept mutex, mpm event seems to work well without any, why prefork and worker would need one (both poll() all the listeners in a single thread, while other children can do the same)? The patch follows and is attached. It can already be tested with a workaround against the defect: don't let perform_idle_server_maintenance() create/stop children after startup (eg. StartServers, ServerLimit, Min/MaxSpareServers using the same value). Thoughts, feedbacks welcome. Regards, Yann. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55897#c7 [2] http://mail-archives.apache.org/mod_mbox/httpd-bugs/201312.mbox/%[email protected]/bugzilla/%3E [3] http://lwn.net/Articles/542629/ and http://lwn.net/Articles/542738/ Index: server/mpm/event/event.c === --- server/mpm/event/event.c(revision 1575322) +++ server/mpm/event/event.c(working copy) @@ -2356,6 +2356,13 @@ static void child_main(int child_num_arg) /*stuff to do before we switch id's, so we have permissions. */ ap_reopen_scoreboard(pchild, NULL, 0); +rv = ap_reopen_listeners(pchild, num_listensocks); +if (rv != APR_SUCCESS) { +ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf, APLOGNO() + "Couldn't re-open listeners"); +clean_child_exit(APEXIT_CHILDFATAL); +} + if (ap_run_drop_privileges(pchild, ap_server_conf)) { clean_child_exit(APEXIT_CHILDFATAL); } Index: server/mpm/prefork/prefork.c === --- server/mpm/prefork/prefork.c(revision 1575322) +++ server/mpm/prefork/prefork.c(working copy) @@ -271,7 +271,9 @@ static void accept_mutex_off(void) * multiple Listen statements. Define SINGLE_LISTEN_UNSERIALIZED_ACCEPT * when it's safe in the single Listen case. */ -#ifdef SINGLE_LISTEN_UNSERIALIZED_ACCEPT +#if HAVE_SO_REUSEPORT +#define SAFE_ACCEPT(stmt) +#elif defined(SINGLE_LISTEN_UNSERIALIZED_ACCEPT) #define SAFE_ACCEPT(stmt) do {if (ap_listeners->next) {stmt;}} while(0) #else #define SAFE_ACCEPT(stmt) do {stmt;} while(0) @@ -536,6 +538,13 @@ static void child_main(int child_num_arg) clean_child_exit(APEXIT_CHILDFATAL); } +status = ap_reopen_listeners(pchild, num_listensocks); +if (status != APR_SUCCESS) { +ap_log_error(APLOG_MARK, APLOG_EMERG, status, ap_server_conf, APLOGNO() + "Couldn't re-open listeners"); +clean_child_exit(APEXIT_CHILDFATAL); +} + if (ap_run_drop_privileges(pchild, ap_server_conf)) { clean_child_exit(APEXIT_CHILDFATAL); } Index: server/mpm/worker/worker.c === --- server/mpm/worker/worker.c(revision 1575322) +++ server/mpm/worker/worker.c
Re: SO_REUSEPORT in the children processes
Am 07.03.2014 18:07, schrieb Yann Ylavic can you please post plaintext instead HTML to lists for me such messages are unreadable after medical operations on both eyes because you override my MUA font settings signature.asc Description: OpenPGP digital signature
