Great!! Thank you very much for sharing this with us!
Thanks,
Yingqi
-Original Message-
From: Yann Ylavic [mailto:ylavic@gmail.com]
Sent: Thursday, October 08, 2015 10:46 AM
To: dev@httpd.apache.org
Cc: Lu, Yingqi
Subject: Better SO_REUSEPORT
Looks like we can do even better/faster
Looks like we can do even better/faster with it (and latest Linux
kernels), soon :)
https://www.mail-archive.com/netdev@vger.kernel.org/msg81804.html
Promising!
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_
l.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 wrote:
> > On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr >
> > wrote:
> >>
> >> My chief concern was that t
Hi Yann,
Thank you very much for your help!
Yingqi
-Original Message-
From: Yann Ylavic [mailto:ylavic@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 wrote:
> On Fri, May 15, 2015 at 11:02
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, b
;> > 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, Yin
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,
> >&
> 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?
>> An
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@gmail.com]
Sent: Thursday, May 14, 2015 4:45 PM
To: httpd
Subject: Re: SO_REUSEPORT
Hi Yingqi,
2 votes already
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
>
> -Origi
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...@intel.com]
Sent: Friday, May 08, 2015 8:58 AM
To: dev@httpd.apache.org
Subject: RE: SO_REUSEPORT
Hi Christophe, Jim
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
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 o
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
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
r your help!
Yingqi
-Original Message-
From: Yann Ylavic [mailto:ylavic@gmail.com]
Sent: Friday, November 07, 2014 7:49 AM
To: httpd
Subject: Re: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk
Hi Yingqi,
thanks for sharing your results.
On Thu, Nov 6, 2014 at 9:12 PM, Lu, Y
1.2 80, with accept_mutex)
> with current trunk version. Comparing against without SO_REUSEPORT patch, we
> see 28% performance gain with 1 listen statement case and 69% gain with 2
> listen statements case.
With the current implementation and a reasonable number of servers
(children) sta
without SO_REUSEPORT patch, we see 28%
performance gain with 1 listen statement case and 69% gain with 2 listen
statements case.
Regarding to the approach that enables each child has its own listen socket, I
did some testing with current trunk version to increase the number of buckets
to be equal
Hi Yann,
I don't mind at all. I will keep discussion following your reply there.
Thanks,
Yingqi
-Original Message-
From: Yann Ylavic [mailto:ylavic@gmail.com]
Sent: Thursday, November 06, 2014 5:00 AM
To: httpd
Subject: Re: Listeners buckets and duplication w/ and w/o SO_REUS
uckets is default to 1 (ListenCoresBucketsRatio is default to 0). Adding
> ListenCoresBucketsRatio is great since user can have control over this.
> However, I am thinking it may be better to make this default at 8. This will
> make the SO_REUSEPORT support to be default enabled (8 buc
better, I am wondering if you guys have plan to put this
> SO_REUSEPORT patch into the stable version.
> If yes, do you have a rough timeline?
The whole feature could certainly be proposed for 2.4.x since there is
no (MAJOR) API change.
On Thu, Nov 6, 2014 at 6:52 AM, Lu, Yingqi wrote:
>
default at 8. This will
make the SO_REUSEPORT support to be default enabled (8 buckets). In case users
are not aware of this new ListenCoresBucketsRatio configurable flag, they can
still enjoy the performance benefits.
Please let me know what you think.
Thanks,
Yingqi
-Original Message-
From
Hi Yann,
Thank you very much for your help!
As this is getting better, I am wondering if you guys have plan to put this
SO_REUSEPORT patch into the stable version. If yes, do you have a rough
timeline?
The performance gain is great from the patch, I just want to more people being
able to
:
> Thank you very much for your help!
>
> Thanks,
> Yingqi
>
> -Original Message-
> From: Yann Ylavic [mailto:ylavic@gmail.com]
> Sent: Wednesday, October 29, 2014 10:34 AM
> To: httpd
> Subject: Re: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on
Thank you very much for your help!
Thanks,
Yingqi
-Original Message-
From: Yann Ylavic [mailto:ylavic@gmail.com]
Sent: Wednesday, October 29, 2014 10:34 AM
To: httpd
Subject: Re: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk
Hi Yingqi,
I'm working
sponses below.
>
> Thanks,
> Yingqi
>
> -Original Message-
> From: Lu, Yingqi [mailto:yingqi...@intel.com]
> Sent: Friday, October 10, 2014 4:56 PM
> To: dev@httpd.apache.org
> Subject: RE: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on
> trunk
>
&g
: dev@httpd.apache.org
Subject: RE: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk
Dear All,
Attached patch is generated based on current trunk. It covers for
prefork/worker/event/eventopt MPM. It supposes to address following issues
regarding to SO_RESUEPORT support vs. current trunk ve
Hi All,
I just want to check if there is any feedback on this? Generated based on trunk
version, this is to remove some code duplications/global variables. This also
removes listener duplication when SO_REUSEPORT is not being used.
For details, please refer to Yann Ylavic's notes a
hen so_reuseport is not supported by the kernel, ap_num_buckets is set to 1.
In any case, there is 1 dedicated listener per bucket.
2. Remove global variables (mpm_listen, enable_default_listeners and
num_buckets). mpm_listen is changed to MPM local. enabled_default_listener is
completely remo
t;> though.
>>
>> Regards,
>> Yann.
>>
>>>
>>> Thanks,
>>> Yingqi
>>>
>>>
>>> -Original Message-
>>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>>> Sent: Tuesday, October 07, 2014 4:19 PM
ions API must not change
> though.
>
> Regards,
> Yann.
>
>>
>> Thanks,
>> Yingqi
>>
>>
>> -Original Message-
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>> Sent: Tuesday, October 07, 2014 4:19 PM
>> To: httpd
@gmail.com]
Sent: Tuesday, October 07, 2014 5:04 PM
To: httpd
Subject: Re: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk
On Wed, Oct 8, 2014 at 1:50 AM, Lu, Yingqi wrote:
> Here is what I think. Currently (trunk version as well as my original
> patch),
>
>
On Wed, Oct 8, 2014 at 1:50 AM, Lu, Yingqi wrote:
> Here is what I think. Currently (trunk version as well as my original patch),
>
> 1. Without SO_REUSEPORT or when available CPU number < 8, num_bucket = 1
> anyway. It duplicates 1 listener and use that for this single bucket. If
Here is what I think. Currently (trunk version as well as my original patch),
1. Without SO_REUSEPORT or when available CPU number < 8, num_bucket = 1
anyway. It duplicates 1 listener and use that for this single bucket. If folks
think we should not duplicate in this case, I can modify the c
Hi,
some notes about the current implementation of this (trunk only).
First, whether or not SO_REUSEPORT is available, we do duplicate the listeners.
This, I think, is not the intention of Yingqi Lu's original proposal,
and probably my fault since I asked for the patch to be splitted in
tw
patch with SO_REUSEPORT
support
Thanks very much for your help!
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Thursday, June 05, 2014 6:38 AM
To: dev@httpd.apache.org
Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Committed r1600656
Thanks very much for your help!
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Thursday, June 05, 2014 6:38 AM
To: dev@httpd.apache.org
Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Committed r1600656
Thx
On Jun 4, 2014, at
based on rev #1600451.
>
> Can you please help add the changes in the trunk?
>
> Thanks,
> Yingqi
>
> -Original Message-
> From: Lu, Yingqi [mailto:yingqi...@intel.com]
> Sent: Tuesday, June 03, 2014 8:50 AM
> To: dev@httpd.apache.org
> Subject: RE: [PATCH A
-
From: Lu, Yingqi [mailto:yingqi...@intel.com]
Sent: Tuesday, June 03, 2014 8:50 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Thank you very much for your help!
Thanks,
Yingqi
-Original Message-
From: Jim Jagielski
Thank you very much for your help!
Thanks,
Yingqi
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Tuesday, June 03, 2014 8:31 AM
To: dev@httpd.apache.org
Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Next on the agenda is to
Next on the agenda is to push into eventopt
On Jun 3, 2014, at 10:21 AM, Jim Jagielski wrote:
> FTR: I saw no reason to try to handle both patches... I used
> the so_reuseport patch as the primary patch to focus on.
>
> I have some minor changes coming up to follow-up post
> the
FTR: I saw no reason to try to handle both patches... I used
the so_reuseport patch as the primary patch to focus on.
I have some minor changes coming up to follow-up post
the initial commit
On Jun 3, 2014, at 8:51 AM, Jim Jagielski wrote:
> I have folded this into trunk and am curren
t; I already updated the Bugzilla database for the item 55897 and item 56279.
>
> Thanks,
> Yingqi
>
> -Original Message-
> From: Lu, Yingqi [mailto:yingqi...@intel.com]
> Sent: Saturday, May 31, 2014 11:48 PM
> To: dev@httpd.apache.org
> Subject: RE: [P
gzilla# 55897]prefork_mpm patch with SO_REUSEPORT
> support
>
>
> How do I unsubscribe from this list ?
>
> Regards,
> Mihai Iacob
> DB2 Security Development
> DB2 pureScale Development
> Phone: (905) 413-5378
> Email: mia...@ca.ibm.com
>
]prefork_mpm patch with
SO_REUSEPORT support
Thanks!
On Jun 2, 2014, at 4:22 AM, Lu, Yingqi wrote:
> Hi Jim,
>
> Personally, I think the second approach is better, it keeps
ap_mpm_pod_signal () and ap_mpm_pod_killpg () exactly as the original ones,
only modifies dummy_connection (
item 56279.
>
> Thanks,
> Yingqi
>
> -Original Message-
> From: Lu, Yingqi [mailto:yingqi...@intel.com]
> Sent: Saturday, May 31, 2014 11:48 PM
> To: dev@httpd.apache.org
> Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
> support
>
> Hi Jim
ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Hi Jim,
Thanks very much for your email! I will look into both of them and send an
update tonight!
Thanks,
Yingqi
> On May 31, 2014, at 9:43 AM, "Jim Jagielski" wrote:
>
> I also see:
>
>
e:
>>>
>>> Thank you very much!
>>>
>>> Thanks,
>>> Yingqi
>>>
>>> -Original Message-
>>> From: Jim Jagielski [mailto:j...@jagunet.com]
>>> Sent: Friday, May 30, 2014 7:07 AM
>>> To: d
; -Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: Friday, May 30, 2014 7:07 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
>> support
>>
>> Thx! Let me review. My pl
ay, May 30, 2014 7:07 AM
> To: dev@httpd.apache.org
> Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
> support
>
> Thx! Let me review. My plan is to fold into trunk this weekend.
>
> On May 16, 2014, at 2:53 PM, Lu, Yingqi wrote:
>
>> Hi Jim,
>
Thank you very much!
Thanks,
Yingqi
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Friday, May 30, 2014 7:07 AM
To: dev@httpd.apache.org
Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Thx! Let me review. My plan is to fold
]prefork_mpm patch with
SO_REUSEPORT support
Thx! Let me review. My plan is to fold into trunk
this weekend.
On May 16, 2014, at 2:53 PM, Lu, Yingqi wrote:
> Hi Jim,
>
> Thanks very much for clarifying this with me. I added #ifdef in the code
to check _SC_NPROCESSORS_ONLN in the so_
Thx! Let me review. My plan is to fold into trunk
this weekend.
On May 16, 2014, at 2:53 PM, Lu, Yingqi wrote:
> Hi Jim,
>
> Thanks very much for clarifying this with me. I added #ifdef in the code to
> check _SC_NPROCESSORS_ONLN in the so_reuseport patch. Bucket patch does not
Hi All,
I just want to ping again on these two patches.
Thanks,
Yingqi
-Original Message-
From: Lu, Yingqi [mailto:yingqi...@intel.com]
Sent: Friday, May 23, 2014 9:03 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
trunk?
Thanks,
Yingqi
-Original Message-
From: Lu, Yingqi [mailto:yingqi...@intel.com]
Sent: Friday, May 16, 2014 11:53 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Hi Jim,
Thanks very much for clarifying this with me. I
]
Sent: Friday, May 16, 2014 11:53 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Hi Jim,
Thanks very much for clarifying this with me. I added #ifdef in the code to
check _SC_NPROCESSORS_ONLN in the so_reuseport patch. Bucket patch
Dear all,
Any other feedback/comments/questions?
Thanks,
Yingqi
-Original Message-
From: Lu, Yingqi
Sent: Wednesday, May 14, 2014 9:00 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Hi Jim,
Thanks very much for your
Dear all,
Any other feedback/comments/questions?
Thanks,
Yingqi
-Original Message-
From: Lu, Yingqi
Sent: Wednesday, May 14, 2014 9:00 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Hi Jim,
Thanks very much for your
Sent: Wednesday, May 14, 2014 9:00 AM
To: dev@httpd.apache.org
Subject: RE: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Hi Jim,
Thanks very much for your email.
In the SO_REUSEPORT patch, SO_REUSEPORT support is checked inside listen.c
file. If the feature is not
Jim,
>
> Thanks very much for your email.
>
> In the SO_REUSEPORT patch, SO_REUSEPORT support is checked inside listen.c
> file. If the feature is not supported on the OS (for example, Linux kernel <
> 3.9), it will fall back to the original behavior.
>
> In the bucket patch,
SO_REUSEPORT
support
Hi Jim,
Thanks very much for your email.
In the SO_REUSEPORT patch, SO_REUSEPORT support is checked inside listen.c
file. If the feature is not supported on the OS (for example, Linux kernel <
3.9), it will fall back to the original behavior.
In the bucket patch, th
Hi Jim,
Thanks very much for your email.
In the SO_REUSEPORT patch, SO_REUSEPORT support is checked inside listen.c
file. If the feature is not supported on the OS (for example, Linux kernel <
3.9), it will fall back to the original behavior.
In the bucket patch, there is no need to ch
re #55897 and
> #56279. Please refer to messages below for details on both of the patches.
>
> Quick test result on modern dual socket Intel platform (Linux Kernel 3.13.9)
> SO_REUSEPORT patch (bugzilla #55897)
> 1. Prefork MPM: 1 listen statement: 2.16X throughput impr
Thanks, Graham! I am looking forward to hearing your feedback.
Thanks,
Yingqi
From: Graham Leggett [mailto:minf...@sharp.fm]
Sent: Monday, April 07, 2014 12:08 PM
To: dev@httpd.apache.org
Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
On 07 Apr 2014, at 6
On 07 Apr 2014, at 6:21 PM, "Lu, Yingqi" wrote:
> I just want to ping again on the modifications we made on both of the patches
> [bugzilla #55897 and bugzilla #56279]. Please let us know your comments and
> feedback.
>
> I am reattaching the patch files here in case you missed original email
@httpd.apache.org
Subject: RE: FW: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Dear all,
I just want to ping on both of these two patches to see if there is anything we
can do to help them get accepted.
Your feedbacks and comments are very much appreciated.
Thanks,
Yingqi Lu
From
@httpd.apache.org
Subject: RE: FW: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Dear all,
Based on the feedback we received, we modified this patch. Here is the most
recent version. We also modified the Bugzilla database(Bugzilla# 55897 for
SO_REUSEPORT patch; Bugzilla
Hi Tim,
Thanks for your email.
SO_REUSEPORT feature is enabled on Linux kernel 3.9 and newer. The feature is
defined at /usr/include/asm-generic/socket.h.
With the old kernel, the definition is there, but is commented out.
/*#define SO_REUSEPORT 15*/
The section of code below is just to
I'm afraid I don't understand this particular part from
httpd_trunk_so_reuseport.patch:
#ifndef SO_REUSEPORT
#define SO_REUSEPORT 15
#endif
Why 15? Is this going to be portable across different platforms?
--
Tim Bannister – is...@jellybaby.net
s 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 an
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 - modera
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 sen
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.
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
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
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 threa
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
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 med
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 H
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 --
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 withou
> Sorry, this was posted from gmail...
FWIW I did not really see the distinctive HTML look and feel reading
it on gmail.
tings
>
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 s
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
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
Hi Yann,
Yes, without SO_REUSEPORT, child only accepts connections from a single
listening socket only. In order to address the situation of in-balanced traffic
among different sockets/listen statements, the patch makes each bucket does its
own idler server maintenance. For example, if we have
t;
> >> ++1.
> >>
> >>
> >> On Mar 6, 2014, at 3:15 AM, Plüm, Rüdiger, Vodafone Group
> >> wrote:
> >>
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: William A. Rowe Jr. [mai
>>
>> On Mar 6, 2014, at 3:15 AM, Plüm, Rüdiger, Vodafone Group
>> wrote:
>>
>> >
>> >
>> >> -Original Message-
>> >> From: William A. Rowe Jr. [mailto:wmr...@gmail.com]
>> >> Sent: Donnerstag, 6. März 2014 06:58
>> >>
lliam A. Rowe Jr. [mailto:wmr...@gmail.com]
> >> Sent: Donnerstag, 6. März 2014 06:58
> >> To: dev@httpd.apache.org
> >> Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with
> >> SO_REUSEPORT support
> >>
> >>
> >> If you
On Wed, Mar 5, 2014 at 11:38 AM, Lu, Yingqi wrote:
> 1. If I understand correctly (please correct me if not), do you suggest
> duplicating the listen socks inside the child process with SO_REUSEPROT
> enabled? Yes, I agree this would be a cleaner implementation and I actually
> tried that before.
SF bugzilla# 55897]prefork_mpm patch with
>> SO_REUSEPORT support
>>
>>
>> If you want to truly re-architect the MPM, by all means, propose it as
>> another MPM module. If it isn't adopted here, please don't hesitate
>> to offer it to interested users as
to
not create/terminate children processes once started (using the same value
for StartServers and ServerLimit, still MaxRequetsPerChild 0).
It could be interesting to see how SO_REUSEPORT scales in these optimal
conditions (no lock, full OS round-robin on all listeners).
For this you would have to use
On 06 Mar 2014, at 10:15 AM, "Plüm, Rüdiger, Vodafone Group"
wrote:
> +1 to a new MPM on trunk. This gives it more time to settle and to stabilize
> without disrupting current stuff. And if it is fast and stable it will
> certainly
> cause the 'older' MPM to drop in userbase :-).
> IMHO this wo
> -Original Message-
> From: William A. Rowe Jr. [mailto:wmr...@gmail.com]
> Sent: Donnerstag, 6. März 2014 06:58
> To: dev@httpd.apache.org
> Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with
> SO_REUSEPORT support
>
>
> If you want to truly r
, 2014 9:58 PM
To: dev@httpd.apache.org
Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with SO_REUSEPORT
support
Yingqi,
as one of the 'Windows folks' here, your idea is very intriguing, and I'm sorry
that other issues have distracted me from giving it the attention it de
On Thursday 06 of March 2014, William A. Rowe Jr. wrote:
> If you want to truly re-architect the MPM, by all means, propose it as
> another MPM module. If it isn't adopted here, please don't hesitate
> to offer it to interested users as separate source (although I hope we
> find a way to adopt it
lization.
>
>
>
> Based on those findings, we created a prototype patch for prefork mpm which
> extends performance and thread utilization. In Linux kernel newer than 3.9,
> SO_REUSEPORT is enabled. This feature allows multiple sockets listen to the
> same IP:port and automatically round ro
gling with myself as well on if we should put with and without
SO_REUSEPORT into two different patches. The only reason I put them together is
because they both use the concept of listen buckets. If you think it would make
more sense to separate them into two patches, I can certainly do that. Als
On Wed, Mar 5, 2014 at 2:04 PM, Yann Ylavic wrote:
> Also, but this is not related to this patch particularly (addressed to
> who knows), it's unclear to me why an accept mutex is needed at all.
> Multiple processes poll()ing the same inherited socket is safe but not
> multiple ones? Is that an O
1 - 100 of 116 matches
Mail list logo
