Re: Is Apache getting too patchy?
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 someone who'll be interested in an idea or patch, and has the time to review it. Plus, the community as a whole to agree it's a good idea, or at least not actively oppose it. That's fine by me. I don't think it necessarily needs to be _easy_ -- making it too easy to submit code loosens the codebase, which I think is what Jim's original mail is asking about -- but at the same time it shouldn't be like talking to a wall. In other words, I find it very difficult to keep a conversation going here, and in my experience, it's the conversations that keep codebases healthy. 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 primary responsibility to see that your ideas don't just fall through the gaps and get ignored? See my reply to Tim. --Jacob
Re: Is Apache getting too patchy?
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 primary responsibility to see that your ideas don't just fall through the gaps and get ignored? How does the word “sponsor” sound? Someone who encourages and champions the development activity around a particular feature (and is also very welcome to contribute). The existing and more formal mechanisms for approving commits seem to work fine as a way of controlling the quality of code. I like "sponsor". In contrast, "primary maintainer" implies (at least to me) a lot of ownership over a section of code, which doesn't seem to fit into the Apache style. Improving the workflow means, to me, coaching and leadership, and different kinds of code review. Someone who isn't very good at C (like me) might well want to make a code contribution but not be sure how. I saw recently how much perseverance Yingqi Lu put in towards getting SO_REUSEPORT support into trunk and then into 2.4.17 – and that's great. It's unfortunate that the same perseverance also offers a lesson about the kind of barriers that a would-be contributor might encounter. So, sponsorship can be about encouraging participation and progress. I'm imagining someone who rarely has to settle a decision – those should stay consensual and democratic - but often leads discussions and moves things on. I like this. So your sponsor's qualities (coaching/servant leadership/facilitation) are primarily to break down the barriers to contribution. I think there are now two topics of conversation, though. To wrap this back around to Jim's question, which was about the "patchiness" of the server (sorry, Jim, for somewhat derailing your thread)... In addition to a sponsor, having someone with "the grand vision" for a section of the server would be good too. Someone who tries to be involved with related patches, to ensure that work in one area does not conflict with other (un)related work... basically, to make sure that a piece of the server is moving in one direction at once. (I would call such a person an "architect", though I think that term is probably loaded with a lot of baggage for those of you in the corporate world.) I don't know if a sponsor and an architect could/should/would be the same person in httpd's case; I don't even know if either of those roles makes sense in Apache culture. And I understand that this is a volunteer project and not a corporation. But from the outside looking in, it would be nice if both roles were filled for various parts of the server. Maybe they already are filled, and I just can't see them? --Jacob
Re: Is Apache getting too patchy?
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 project. If individual contributors are each trying to "scratch their own itch", then there would be a tendency for code to become less coherent over time. What keeps things from growing into chaos is the review by experienced contributors who are looking at the overall purpose and direction of the project as a whole. Another thing that helps the Apache HTTP Server project is the modular design of the code base. New and diverse features can be isolated into separate modules, be given time to mature and then eventually be better integrated with the core code. Over the last few months there simply has been a lot of activity. But there has also been a lot of quality debate around this activity. Some very impressive new functionality has been attempted. I personally have not had enough time (and possibly not enough skill) to know if the quality of the code is good or not. But from my limited perspective the discussions seem to be going in a good direction. Thanks, Mike Rumph On 10/24/2015 8:49 AM, Jim Jagielski wrote: Just some food for thought; let me know if I'm off the rails. Over the last several months, it's appeared to me that we have been adding patches that feel, well, very-patchy to me. They feel like cumbersome add-ons that create some level of fragility to our code, with special one-off considerations instead of a deeper more complete fix. In other words, it seems that httpd is becoming more crufty rather than planned and cohesive and consistent. Thoughts? Comments?
Re: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)
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. [Yingqi Lu , > > Jeff Trawick, Jim Jagielski, Yann Ylavic] > > Both patches might come to solve similar problem, but SO_REUSEPORT requires > Linux 3.9 (which is quite new in Linux terms). Maybe this requirement could be relaxed so that the listeners buckets (and their own accept mutex) would be available even without the SO_REUSEPORT option. Could you test this? Regards, Yann.
Re: Is Apache getting too patchy?
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 not be easy. You need to find someone who'll be interested in an > idea or patch, and has the time to review it. > Plus, the community as a whole to agree it's a good idea, or at least not > actively oppose it. > > 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 primary responsibility to see > that your ideas don't just fall through the gaps and get ignored? How does the word “sponsor” sound? Someone who encourages and champions the development activity around a particular feature (and is also very welcome to contribute). The existing and more formal mechanisms for approving commits seem to work fine as a way of controlling the quality of code. Improving the workflow means, to me, coaching and leadership, and different kinds of code review. Someone who isn't very good at C (like me) might well want to make a code contribution but not be sure how. I saw recently how much perseverance Yingqi Lu put in towards getting SO_REUSEPORT support into trunk and then into 2.4.17 – and that's great. It's unfortunate that the same perseverance also offers a lesson about the kind of barriers that a would-be contributor might encounter. So, sponsorship can be about encouraging participation and progress. I'm imagining someone who rarely has to settle a decision – those should stay consensual and democratic - but often leads discussions and moves things on. Comments very welcome. -- Tim Bannister – is...@c8h10n4o2.org.uk
Re: Is Apache getting too patchy?
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 > discussion/debate. > 2) Nothing happens. > 3) List is pinged for comments. > 4) Silence. > 5) Patch author either gives up or pings relentlessly until... > 6) ...patch is applied directly to trunk without discussion. Thanks for the perspective. Yes, it's sometimes uncomfortable. > 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 someone who'll be interested in an idea or patch, and has the time to review it. Plus, the community as a whole to agree it's a good idea, or at least not actively oppose it. 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 primary responsibility to see that your ideas don't just fall through the gaps and get ignored? -- Nick Kew
Re: Is Apache getting too patchy?
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, very-patchy to me. They > feel like cumbersome add-ons that create some level of fragility > to our code, with special one-off considerations instead of a > deeper more complete fix. In other words, it seems that httpd is > becoming more crufty rather than planned and cohesive and > consistent. > So over an arbitrary window of time (several months = 12 weeks?) there are patches that you are uncomfortable with on trunk? 2.4? Perhaps even 2.2? They seem to be fingers in the dam, rather than reinforcing the wall of a solid code base? Rather than 'vaugebooking' (to borrow a phrase from another context), it might be helpful to point out the specific commits that have you concerned, and register specific complaints or feedback? If a -1 is called for, of course put that forward, but perhaps some coaching/coaxing might get the specific fixes into the sort of shape you feel is appropriate? If there is a pattern from specific committers, pointing out any issues on one patch is probably sufficient to coax them into reviewing their other patches for similar issues and avoid any similar issues in the future? Some parts of trunk are certainly due for refactoring, but that can be a multi-week task rather than the obvious quick fix. If there is a better or more comprehensive fix, calling it out on the list might solicit rework from yet another committer who is interested in the same issue at hand? As a committer and PMC member, it is yours, and mine, and all the rest of the project participants to point out problematic commits individually. That's the definition of commit-then-review, something you recently championed an expansion of for more aspects of the 2.4 branch. Please pipe up on the -r phase so we all learn which patches concerns you, and why?
Re: Thx and merit
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 you can check with Jim and let us know the exact URL > where the Apache 2.1.4 H2C module can be accessed from. > > Many thanks > Istvan > > -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: 14 October 2015 15:55 > To: dev@httpd.apache.org > Cc: Dan Druta ; Istvan Lajtos ; OSCAR DE > DIOS GONZALEZ ; Reschke Julian > ; Böttcher Martin > > Subject: Re: Thx and merit > > Thanks to everyone for the kind words. It has been my pleasure to contribute > to such a community as Apache and I plan on continuing doing so as much as > possible. > > Many thanks to Jim, Eric, Yann, Rainer, Kaspar and all the others that have > made me welcome here right from the start and who helped me settle in. It's a > project with an immense history and there is always something more to learn > about it. > > When Apache httpd now speaks HTTP/2, then it's mainly Tatsuhiro Tsujikawa's > work in nghttp2 that made this feasible. > Many thanks to his excellent work and his nice support! > > As Jeff wrote: this all would not have happened if not for the sponsoring of > the GSMA and Telefonica. Particularly Dan Druta and Istvan Lajtos have been > driving the idea from the start and Oscar Gonzalez accompanied the project in > its execution phase. Great work! > > My employer, greenbytes, is also partly my company, so I could thank myself. > However my partners, Julian Reschke and Martin Böttcher, also deserve thanks > for supporting this endeavor. > > We are but a very small company and it is not possible to sponsor a full time > person for a long duration. We will continue looking for sponsors to do work > in Apache. Such projects really give the greatest worth for all parties > involved as can be seen today. > > Again, Thanks! > > //Stefan > >> Am 14.10.2015 um 16:20 schrieb Yann Ylavic : >> >> +1, thanks Stefan! >> >>> On Wed, Oct 14, 2015 at 2:58 PM, Jim Jagielski wrote: >>> The ASF is all about recognizing and rewarding merit. The whole >>> "Apache Way" started here, with this project, and httpd has always >>> been the sort of "guiding light" and example of how Apache projects >>> (should) work. >>> >>> Inclusion of the HTTP/2 implementation for httpd, especially for the >>> 2.4.x branch, is a substantial feather in our cap. But we would have >>> been far behind the 8-ball if not for the funding by the GSM >>> Association on greenbytes GmbH's mod_h2 work, and for the donation of >>> that module to the ASF. >>> >>> Once again, I'd like to thank them personally! > > This email and its attachments are intended for the above named only and may > be confidential. If they have come to you in error you must take no action > based on them, nor must you copy or show them to anyone; please reply to this > email or call +44 207 356 0600 and highlight the error.
Re: Is Apache getting too patchy?
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 feedback. Cool, we're in agreement then. --Jacob
Re: Enforce rewriting of Host header when an absolue URI is given
> 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 default, not only with "HttpProtocol strict", which is trunk only btw). >> >> Per RFC7230#section-5.4 : >>When a proxy receives a request with an absolute-form of >>request-target, the proxy MUST ignore the received Host header field >>(if any) and instead replace it with the host information of the >>request-target. A proxy that forwards such a request MUST generate a >>new Host field-value based on the received request-target rather than >>forward the received Host field-value. >> >> The first part is already honored, but not the forwarding part: the >> Host header is not rewritten with the one extracted from the absolute >> URI, neither at the protocol (core) level nor at proxy level. >> >> There are PR56718 (and duplicate PR57563) about this. >> Still the same question about whether providing the headers to some >> CGI or module is a forward or not, > > I don't buy this. IMO, CGI/plugins/modules/etc. are implementation details of > the server. Correct. The word "proxy" in HTTP only applies to to the forwarding of HTTP messages by a client-selected (forward) proxy. There was no such thing as a "reverse proxy" (an idiotic marketing term invented by Netscape) when the original HTTP specs were written. Those are gateways (as in Common Gateway Interface). >> I think personally it would be sane >> to do this at the protocol level (beginning of the request). >> I proposed a patch there and refined it a bit (attached), so that >> section 5.4 is applied in vhost.c::fix_hostname(). >> >> It also implements this part of section 5.4 (second point, _underlined_) : >>A server MUST respond with a 400 (Bad Request) status code to any >>HTTP/1.1 request message that lacks a Host header field and _to any >>request message that contains more than one Host header field_ or a >>Host header field with an invalid field-value. >> >> The first point is already handled, and the third is "HttpProtocol >> strict" dependent (which is enough I think, but maybe deserve a >> backport too). We should always be strict on received Host handling because misplaced routing information is often used to bypass security filters. That is, we should not allow an invalid Host header field to pass through. It should at least be rejected by default (if non-reject is configurable). Roy
Re: Is Apache getting too patchy?
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 traded one bad > extreme (where few people care about the quality of the codebase) for > another (where the people who care about the codebase are rude and > uncooperative). You can be hard-nosed about code standards without being a > jerk. > > Maybe you didn't mean it like that, but I feel like there are way too many > people in open source communities who take an "I have to be an asshole" > mantra to heart. 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 feedback. I've seen way too many instances (not limited to this project) of ill-advised or badly implemented changes being accepted because no one was willing to be the "bad guy" and say "No, that change will not be accepted." This has been a major problem with the Zsh project, for example. To the point where I'm seriously considering switching shells. I'd hate to see that happen to this project. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank
Re: Enforce rewriting of Host header when an absolue URI is given
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 RFC7230#section-5.4 : When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value. The first part is already honored, but not the forwarding part: the Host header is not rewritten with the one extracted from the absolute URI, neither at the protocol (core) level nor at proxy level. There are PR56718 (and duplicate PR57563) about this. Still the same question about whether providing the headers to some CGI or module is a forward or not, I don't buy this. IMO, CGI/plugins/modules/etc. are implementation details of the server. I think personally it would be sane to do this at the protocol level (beginning of the request). I proposed a patch there and refined it a bit (attached), so that section 5.4 is applied in vhost.c::fix_hostname(). It also implements this part of section 5.4 (second point, _underlined_) : A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and _to any request message that contains more than one Host header field_ or a Host header field with an invalid field-value. The first point is already handled, and the third is "HttpProtocol strict" dependent (which is enough I think, but maybe deserve a backport too). Thoughts? I have conflicting feelings on your approach, but I haven't pinned down a good argument against it. So here's an alternative for the sake of discussion: instead of rewriting the request to try to prevent downstream security issues (and allowing a request that is probably malicious to stay alive), why not reject the request outright? Any non-malicious uses of a mismatched Host will be broken by this patch anyway, right? --Jacob
Re: Is Apache getting too patchy?
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 (where the people who care about the codebase are rude and uncooperative). You can be hard-nosed about code standards without being a jerk. Maybe you didn't mean it like that, but I feel like there are way too many people in open source communities who take an "I have to be an asshole" mantra to heart. --Jacob
Re: Is Apache getting too patchy?
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) Nothing happens. 3) List is pinged for comments. 4) Silence. 5) Patch author either gives up or pings relentlessly until... 6) ...patch is applied directly to trunk without discussion. This being a volunteer project, I don't actually mind steps 1-5 so much. You're busy people, and my patches shouldn't be priority one for anyone. I'm more concerned about step 6, where conversations wither on the vine in favor of just applying the patch and seeing what happens. I think that could contribute to the "cruft instead of cohesion" that you're seeing. 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. HTH, --Jacob
Re: Question about CACHE_SEPARATOR in modules/cache/cache_util.h
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" from the > beginning. But I think Graham pointed into the right direction, probably it > should have been "comma-space-tab”. Following the links further into the RFC, this corresponds with LWS, which is either a space or a tab: #define CACHE_SEPARATOR “, \t" Regards, Graham —
Re: Question about CACHE_SEPARATOR in modules/cache/cache_util.h
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 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, or can it be turned in: #define CACHE_SEPARATOR ", “ Double check whether the spaces are significant, it might be a space and a tab (which would be weird, because it should just say /t then). This might have RFC compliance issues if it was changed, we need to verify what the code does. 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" from the beginning. But I think Graham pointed into the right direction, probably it should have been "comma-space-tab". Regards, Rainer
RE: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)
>Just to clarify, all updates to httpd need to be made to trunk first, which >then allow it to be backported to v2.4, and then v2.2. >The reason for this is we don’t want features added to v2.2 that then >subsequently vanish when v2.4 comes out (and so on). Understood. I just want to get some feedback about my initial implementation. If there will be interest – I’ll be glad to write an updated patch to be applied to trunk. >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. [Yingqi Lu mailto:yingqi...@intel.com>>, Jeff Trawick, Jim Jagielski, Yann Ylavic] Both patches might come to solve similar problem, but SO_REUSEPORT requires Linux 3.9 (which is quite new in Linux terms). Thanks for the feedback, Yehezkel Horowitz Check Point Software Technologies Ltd.
RE: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)
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 version) doesn't support it. The patch worked for me very well, but I'm not sure I didn't missed some pitfalls, which someone with much more knowledge about Apache internals (specially on Linux) will easily see. >How well does your patch apply to trunk? You can't apply my patch to 2.4 or trunk, as since 2.4 there is a "prefork_child_bucket" concept, which I don't fully understand its role (and how it relate to other MPMs). I'll be happy to write an updated patch if someone could explain me the role of the "prefork_child_bucket". Regards, Yehezkel Horowitz Check Point Software Technologies Ltd.
Re: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)
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 you convenience.… Just to clarify, all updates to httpd need to be made to trunk first, which then allow it to be backported to v2.4, and then v2.2. The reason for this is we don’t want features added to v2.2 that then subsequently vanish when v2.4 comes out (and so on). 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. [Yingqi Lu , Jeff Trawick, Jim Jagielski, Yann Ylavic] Regards, Graham —
Re: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)
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 Enhancement request in Bugzilla would leave a record of it. > 1. Do you think this is a good implementation of the suggested > idea? If a threaded MPM really isn't an option (for most users the obvious solution), then the question is what works for you. > 3. Would you consider accepting this patch to the project? > If so, could you guide me what else needs to be done for acceptances? > I know there is a need for configuration & documentation work - I’ll > work on once the patch will be approved… Unlikely it would get in to a future 2.2 release unless it fixed something much more than an arcane performance problem (arcane because because it only happens when you reject conventional ways to boost performance, like another MPM). How well does your patch apply to trunk? If you don't want to go in that direction, you could post somewhere always available for anyone interested. Our bugzilla would serve, as would somewhere else you publish from, like github or a personal site. -- Nick Kew
Re: Question about CACHE_SEPARATOR in modules/cache/cache_util.h
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' and scanning 3 times for the > same thing is just a waste of time. > > Did I miss something obvious, or can it be turned in: > > #define CACHE_SEPARATOR ", “ Double check whether the spaces are significant, it might be a space and a tab (which would be weird, because it should just say /t then). This might have RFC compliance issues if it was changed, we need to verify what the code does. Regards, Graham —
RE: Question about CACHE_SEPARATOR in modules/cache/cache_util.h
> -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 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, or can it be turned in: I cannot see any obvious here either. If it is needed for whatever reason it at least deserves a comment to avoid this question in the future :-). Regards Rüdiger
RE: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)
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 Horowitz Sent: Monday, October 19, 2015 6:14 PM To: dev@httpd.apache.org Subject: Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached) Hello Apache gurus. I was working on a project which used Apache 2.2.x with prefork MPM (using flock as mutex method) on Linux machine (with 20 cores), and run into the following problem. During load, when number of Apache child processes get beyond some point (~3000 processes) - Apache didn't accept the incoming connections in reasonable time (seen in netstat as SYN_RECV). I found a document about Apache Performance Tuning [1], in which there is an idea to improve the performance by: "Another solution that has been considered but never implemented is to partially serialize the loop -- that is, let in a certain number of processes. This would only be of interest on multiprocessor boxes where it's possible that multiple children could run simultaneously, and the serialization actually doesn't take advantage of the full bandwidth. This is a possible area of future investigation, but priority remains low because highly parallel web servers are not the norm." I wrote a small patch (aligned to 2.2.31) that implements this idea - create 4 mutexes and spread the child processes across the mutexes (by getpid() % mutex_number). So in any given time - 4 ideal child processes are expected [2] to wait in the "select loop". Once a new connection arrive - 4 processes are awake by the OS: 1 will succeed to accept the socket (and will release his mutex) and 3 will return to the "select loop". This solved my specific problem and allowed me to get more load on the machine. My questions to this forum are: 1. Do you think this is a good implementation of the suggested idea? 2. Any pitfalls I missed? 3. Would you consider accepting this patch to the project? If so, could you guide me what else needs to be done for acceptances? I know there is a need for configuration & documentation work - I'll work on once the patch will be approved... 4. Do you think '4' is a good default for the mutexes number? What should be the considerations to set the default? 5. Does such implementation relevant for other MPMs (worker/event)? Any other feedback is welcome. [1] http://httpd.apache.org/docs/2.2/misc/perf-tuning.html, accept Serialization - Multiple Sockets section. [2] There is no guarantee that exactly 4 processes will wait as all processes of "getpid() % mutex_number == 0" might be busy in a given time. But this sounds to me like a fair limitation. Note: flock give me the best results, still it seems to be with n^2 complexity (where 'n' is the number of waiting processes), so reducing the number of processes waiting on each mutex give exponential improvement. Regards, Yehezkel Horowitz Check Point Software Technologies Ltd. multi-accept-mutexes.patch Description: multi-accept-mutexes.patch
Question about CACHE_SEPARATOR in modules/cache/cache_util.h
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, or can it be turned in: #define CACHE_SEPARATOR ", " Best regards, CJ
