Re: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)

2015-10-26 Thread Graham Leggett
On 26 Oct 2015, at 10:45 AM, Yehezkel Horowitz wrote: > Any chance someone could take a short look and provide me a feedback (of any > kind)? > > I know your focus is on 2.4 and trunk, but there are still many 2.2 servers > out there… > > Patch attached again for

RE: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)

2015-10-26 Thread Yehezkel Horowitz
First, thanks Nick for the feedback. I have submitted https://bz.apache.org/bugzilla/show_bug.cgi?id=58550 as you suggested. >If a threaded MPM really isn't an option (for most users the obvious >solution), then the question is what works for you. I can't use threaded MPM as PHP (at least my

Re: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)

2015-10-26 Thread Nick Kew
On Mon, 2015-10-26 at 08:45 +, Yehezkel Horowitz wrote: > Any chance someone could take a short look and provide me a feedback > (of any kind)? A patch posted here may get lost, especially if it's not simple and obvious enough for instant review and understanding. Posting it as an

RE: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)

2015-10-26 Thread Yehezkel Horowitz
Any chance someone could take a short look and provide me a feedback (of any kind)? I know your focus is on 2.4 and trunk, but there are still many 2.2 servers out there... Patch attached again for you convenience Yehezkel Horowitz Check Point Software Technologies Ltd. From: Yehezkel

Question about CACHE_SEPARATOR in modules/cache/cache_util.h

2015-10-26 Thread Christophe JAILLET
Hi, in modules/cache/cache_util.h, CACHE_SEPARATOR is defined as: #define CACHE_SEPARATOR ", " I don't see any reason to have 3 spaces here. It is only used within calls to 'cache_strqtok' and scanning 3 times for the same thing is just a waste of time. Did I miss something obvious,

RE: Question about CACHE_SEPARATOR in modules/cache/cache_util.h

2015-10-26 Thread Plüm , Rüdiger , Vodafone Group
> -Original Message- > From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr] > Sent: Montag, 26. Oktober 2015 08:06 > To: dev@httpd.apache.org > Subject: Question about CACHE_SEPARATOR in modules/cache/cache_util.h > > Hi, > > in modules/cache/cache_util.h, CACHE_SEPARATOR is

Re: Question about CACHE_SEPARATOR in modules/cache/cache_util.h

2015-10-26 Thread Graham Leggett
On 26 Oct 2015, at 9:05 AM, Christophe JAILLET wrote: > in modules/cache/cache_util.h, CACHE_SEPARATOR is defined as: > > #define CACHE_SEPARATOR ", " > > > I don't see any reason to have 3 spaces here. > It is only used within calls to 'cache_strqtok'

Re: Is Apache getting too patchy?

2015-10-26 Thread William A Rowe Jr
On Sat, Oct 24, 2015 at 10:49 AM, Jim Jagielski wrote: > Just some food for thought; let me know if I'm off the rails. > Well, that depends on what you are commenting on... Over the last several months, it's appeared to me that we have > been adding patches that feel, well,

Re: Is Apache getting too patchy?

2015-10-26 Thread Nick Kew
On Mon, 26 Oct 2015 09:51:43 -0700 Jacob Champion wrote: > I'm somewhat on the outside looking in, as an httpd newbie. But my > standard experience (it's happened two or three times now) is this: > > 1) Non-trivial patch is proposed to the list with calls for >

Re: Is Apache getting too patchy?

2015-10-26 Thread Tim Bannister
On 26 Oct 2015, at 22:23, Nick Kew wrote: > On Mon, 26 Oct 2015 09:51:43 -0700 > Jacob Champion wrote: > >> I'd rather not feel like I'm just annoying dev@ until you submit my >> stuff -- I want to *talk* about it, and improve the server. > > That may

Re: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)

2015-10-26 Thread Yann Ylavic
On Mon, Oct 26, 2015 at 12:45 PM, Yehezkel Horowitz wrote: > >>The following patch was recently backported to v2.4, how similar is your >> patch to this one? > >> *) MPMs: Support SO_REUSEPORT to create multiple duplicated listener > > records for scalability.

Re: Is Apache getting too patchy?

2015-10-26 Thread Mike Rumph
Hello Jim, As Bill pointed out, it would be helpful if you could identify some specific details within the general trend you are observing. But the kind of thing that you are mentioning is something that I would expect to happen far more often than can be observed in the Apache HTTP Server

Re: Is Apache getting too patchy?

2015-10-26 Thread Jacob Champion
On 10/26/2015 03:40 PM, Tim Bannister wrote: On 26 Oct 2015, at 22:23, Nick Kew wrote: I wonder if workflow would be improved if we had named maintainers for particular parts of the codebase - for example individual modules? Not necessarily to do all the work, but to take

Re: Is Apache getting too patchy?

2015-10-26 Thread Jacob Champion
On 10/26/2015 03:23 PM, Nick Kew wrote: On Mon, 26 Oct 2015 09:51:43 -0700 Jacob Champion wrote: I'd rather not feel like I'm just annoying dev@ until you submit my stuff -- I want to *talk* about it, and improve the server. That may not be easy. You need to find

Re: Question about CACHE_SEPARATOR in modules/cache/cache_util.h

2015-10-26 Thread Graham Leggett
On 26 Oct 2015, at 2:15 PM, Rainer Jung wrote: > The line goes back to > > https://bz.apache.org/bugzilla/show_bug.cgi?id=50199 > > where Nick reported the problem and Graham provided the initial patch. > > The defined tokenizer chars were "comma-space-space-space"

Re: Question about CACHE_SEPARATOR in modules/cache/cache_util.h

2015-10-26 Thread Rainer Jung
Am 26.10.2015 um 10:11 schrieb Graham Leggett: On 26 Oct 2015, at 9:05 AM, Christophe JAILLET wrote: in modules/cache/cache_util.h, CACHE_SEPARATOR is defined as: #define CACHE_SEPARATOR ", " I don't see any reason to have 3 spaces here. It is only

Re: Enforce rewriting of Host header when an absolue URI is given

2015-10-26 Thread Jacob Champion
Yann, I found this while trying to understand the corner cases for Origin header checks for mod_websocket, and I do actually have some thoughts on it... On 03/04/2015 07:21 AM, Yann Ylavic wrote: (by default, not only with "HttpProtocol strict", which is trunk only btw). Per

Re: Enforce rewriting of Host header when an absolue URI is given

2015-10-26 Thread Roy T. Fielding
> On Oct 26, 2015, at 10:33 AM, Jacob Champion wrote: > > Yann, > > I found this while trying to understand the corner cases for Origin header > checks for mod_websocket, and I do actually have some thoughts on it... > > On 03/04/2015 07:21 AM, Yann Ylavic wrote: >> (by

Re: Is Apache getting too patchy?

2015-10-26 Thread Kurtis Rader
On Mon, Oct 26, 2015 at 9:56 AM, Jacob Champion wrote: > On 10/24/2015 09:32 PM, Kurtis Rader wrote: > >> People reviewing changes to the existing code base have to be hard-nosed >> assholes. >> > > Kurtis, > > I agree with everything you said except this. IMHO, you've

Re: Is Apache getting too patchy?

2015-10-26 Thread Jacob Champion
On 10/24/2015 09:32 PM, Kurtis Rader wrote: People reviewing changes to the existing code base have to be hard-nosed assholes. Kurtis, I agree with everything you said except this. IMHO, you've traded one bad extreme (where few people care about the quality of the codebase) for another

Re: Is Apache getting too patchy?

2015-10-26 Thread Jacob Champion
On 10/24/2015 08:49 AM, Jim Jagielski wrote: Thoughts? Comments? Jim, I'm somewhat on the outside looking in, as an httpd newbie. But my standard experience (it's happened two or three times now) is this: 1) Non-trivial patch is proposed to the list with calls for discussion/debate. 2)

Re: Thx and merit

2015-10-26 Thread Stefan Eissing
Hi Istvan, the module has been released as part of the httpd server in version 2.4.17 and can be downloaded from here: http://httpd.apache.org/download.cgi Best Regards, Stefan > Am 26.10.2015 um 18:05 schrieb Istvan Lajtos : > > Hello Stefan > > I would appreciate if

Re: Is Apache getting too patchy?

2015-10-26 Thread Jacob Champion
On 10/26/2015 10:52 AM, Kurtis Rader wrote: Asshole was probably not the best term. I meant it in the sense that you shouldn't be afraid to tell someone in plain language what the problems are with their proposed change. Yes, the reviewer should be polite. No, they should not sugar-coat their