httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Another day, another veto (Was: Optimising ap_location_walk())
Date Mon, 25 Oct 2010 11:02:10 GMT
On 25 Oct 2010, at 11:51 AM, William A. Rowe Jr. wrote:

>> Wow, the very first contribution to the discussion is a veto, and  
>> you've vetoed code that
>> doesn't even exist yet. Crickey, the *ideas* behind what code might  
>> be attempted haven't
>> been fleshed out yet and you're already waving a veto around.
>
> No, I voted against a concept (of throwing everything against the  
> wall at once),
> that wasn't even a veto.

-1 in ASF speak is a veto. When people mention -1 without it being a  
veto, they declare it so in brackets. Me personally, I just say "I  
disagree" and leave it at that so there is no opportunity for confusion.

> If you can find 3 +1's, I already asserted that I'd reverse that  
> position,
> as my primary issue is a lack of review.

A lack of review on a piece of code that doesn't exist yet, within a  
discussion that hasn't finished yet, based on research that hasn't  
been concluded yet.

The reason I initiated this discussion was that I was hoping that  
people would highlight the potential impact of making a change here.  
Obviously it's at the core, obviously it needs to be done carefully,  
obviously servers with few locations cannot suffer for the benefit of  
servers with many. In my experience with the httpd code, most  
optimisations are really simple, and involve minimal code changes, a  
testament to the careful design that has gone into this code at the  
start. I see no reason why future code changes should be any  
different. I am dismayed that people who would contribute to this  
discussion are scared off by a waving veto.

> Right now, I'm staring at development in mod_cache that makes no  
> sense,
> other than bandaids and bubblegum over operational flaws, while we  
> have
> underlying logic between the datastore provider that thinks httpd, and
> the mod_cache protocol module which is dealing with storage questions.
> And you are asking to refactor *what* next?  Eeek!

If you don't understand how the cache works, *ask*.

I designed the thing in the first place. I wrote mod_proxy for v2.0  
from scratch in a Swedish hotel room when the filter stack first  
appeared, and I took the original 1.3 cache out of mod_proxy into a  
separate filter based framework, while others fleshed mod_cache out  
until it worked. Can it be done better? Yes, thus the recent work on it.

For us, one of the world's biggest global media networks serving an  
audience of tens of millions of people every hour, mod_cache sits in  
front of our restful service layer, amongst many other places. We  
learned three key things from this experience:

- Many developers for the web don't know what RFC2616 caching is.  
Unlike us, starting out when the net ran slower than morse code, some  
developers have never encountered a slow net connection before, and  
have never had to know or care about a cache. We went on an education  
drive, demonstrated the orders of magnitude improvement in speed that  
HTTP caching offers in a restful environment, and now our developers  
can't get enough of it.

- All the HTTP caches we tried, those built into load balancers, those  
built into dedicated proxy servers, and mod_cache, have common edge  
case bugs in them, particularly the notorious "leaking 304" problem  
caused when developers don't take care of the caching headers they  
send with a 304 Not Modified from their RFC2616 conditional request  
supporting service. mod_cache's key bugs have been fixed, and it is  
now fully RFC2616 compliant, not just selectively so.

- The httpd filter stack rocks, hard. The fact that we can now  
selectively insert mod_cache anywhere in the filter stack, rocks even  
harder. By "rocks" I mean "saves an enormous amount of money".

If you don't believe the mod_cache provider API is correct, then  
identify specific things about the API you do not believe are correct  
and allow me to fix them for you. Hand waving descriptions like  
"bubblegum" and "operational flaws" are entirely unhelpful and  
contribute nothing towards fixing the problems you believe exist.

Understand that wholesale massive reorganisation of the cache will  
very likely not get the review it requires, just as you've pointed out  
for ap_location_walk(), so distill them down into discrete changes  
that can be applied in simple to understand patches.

Anything that involves making mod_cache.h's public interface smaller,  
a big +1 to that. We can always refactor the cache internally at a  
future date, we can't change a public API after 2.4 has been branched  
(until v2.6, obviously). Anything that identifies functions we are  
exporting unnecessarily, +1 to that too.

And if we can do the same thing on the excessively-public mod_proxy.h  
header, +1 to that too.

> What I was trying to say, however untactfully, is that I wouldn't be  
> very
> supportive of the same approach to core code.  And reading the rest  
> of your
> reply, I think we are of the same mind.
>
> FWIW I didn't conflate anything, I understood each of the aspects of  
> the
> proposal you put forward as "one change".  If you can break down your
> proposal into digestible pieces, I'll support any demonstrable  
> worthwhile
> piece you put forward.  I'm simply asking for no repeats of the  
> current
> state of cache/proxy/ldap/etc etc.  And I don't really think you  
> disagree.
>
> Pick a piece to discuss, and I'm happy to respond.

Will follow this up in the original thread.

Regards,
Graham
--


Mime
View raw message