httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Hamilton" <williamhamil...@sbcglobal.net>
Subject Re: consider reopening 1.3
Date Mon, 17 Nov 2003 07:38:22 GMT
bravo!
----- Original Message -----
From: <TOKILEY@aol.com>
To: <dev@httpd.apache.org>
Cc: <scrappy@hub.org>; <TOKILEY@aol.com>
Sent: Sunday, November 16, 2003 11:05 PM
Subject: Re: consider reopening 1.3


>
> Geez... it's nice to discover everybody hasn't just dropped dead!
>
> I see a lot of healthy 'things to do' coming out of this
> thread that could inject a lot of life back into the
> development... which is what the various threads the past
> few days have all been about.
>
> Action items?...
>
> Facts to face?...
>
> ------
> FACT?: Apache 2.0 pre-fork ( which is the only thing still available on
> some of the best platforms ) is SLOWER than Apache 1.3 pre-fork.
> ------
>
> This gives someone who might be stuck with one of those pre-fork
> only platforms, or anyone who just WANTS to stick with pre-fork,
> absolutely NO INCENTIVE to upgrade at all ( ever! ).
>
> The whole module-rewrite thing is another issue but as long as
> the same process model is SLOWER in the 'new' version than the
> 'old' version you have a serious migration roadblock that
> isn't going to go away.
>
> Okay... problem identified... what to do?
>
> - Verify that's it's true. ( seems to be ). You have to
>   KNOW, yourselves, where you are on the stopwatch and not
>   wait for usrs to tell you.
> - If it's not (true)... do some marketing and make sure people KNOW IT.
> - If it is... fix it. Make it NOT TRUE.
>
> I popped off and looked at 2.0 code again just now and I can tell
> you right now it's (still) the filtering that's killing it.
>
> The core filters are going to need to be totally optimized
> and kick-ass if there's any chance of 2.0 matching 1.3 speed...
> and that's before anybody loads any 'extra' (optional)
> filters ( other than core ).
>
> I don't think this is something any one person can do considering
> no one seems to really have the 'whole picture' of the filtering
> at this point and the orignal (primary) author is gone.
>
> I have a few suggestions but I'm not even sure I have
> the 'whole picture' on how to improve things.
>
> One idea, of course, is to code in some BYPASSES ( on a config
> switch? Dunno ) that would allow 2.0 pre-fork core filters to not
> actually use the filtering (scheme) at all and put it right back
> into 1.3 performance range.
>
> I am by no means suggesting you bring back BUFF for the core
> filters... but I AM suggesting there might be ways to
> BYPASS all the BUCKET_BRIGADE stuff at the core level, if
> that's the way someone wants to run it.
>
> The moment someone starts loading a lot of 'optional' modules
> you'd probably have to re-engage the filtering but I'll bet
> you a dollar to a donut there are a LOT of people running Apache
> with nothing but out-of-the-box options and CORE filters only.
>
> You might even be suprised how MANY people just run it that way.
>
> I think you would see a MAJOR bump in 2.0 usage numbers
> if there was any way 2.0 pre-fork could be FASTER than 1.3
> in a same-box same-environment scenario.
>
> You can't really fix the module-migration roadblock nearly
> as easily as you could FIX THIS.
>
> -----
> FACT?: There are still some non-maintenance mode things that
> people have already expressed they would like to see added
> to 1.3.x and probably more 'ideas' lurking nearby.
> -----
>
> I say... let it happen.
>
> Whether it was 'officially' closed or not... when someone
> can't get a 2 line logging patch added to 1.3 after 6
> months of trying then that is CLOSURE no matter how you
> look at it. Make it not so.
>
> Just let it be known that 'worthy' additions to 1.3
> are still WELCOME and maybe some fresh air will blow
> in the window.
>
> -----
> FACT?: One of the biggest roadblocks to 2.0 migration is
> ( and will remain ) module migration.
> -----
>
> No one even knows how many freakin' 'in-house' modules there
> are out there ( security, auditing, billing, etc. ) that people
> depend on for their 'business' needs but you can be sure those
> 'in-house' modules are what bring home their bacon and are
> MORE important to them than Apache itself.
>
> In a lot of cases these people are using (private) modules
> written FOR them by someone who is long... long gone and
> they really don't have the faintest idea how to get it
> 'migrated' to some 'new version'.
>
> It's too late to talk about total forward-backward compatibility
> for 1.3 and 2.0 modules ( that opportunity was already blown
> at the design stage ) but it IS POSSIBLE to start a discussion
> about providing better 'compatibility' between modules.
>
> Example: If a simple Apache 1.3 module is already NOT using
> APR but simply relies on the old BUFF API wrappers... it's
> perfectly possible to just 'load' that module and run it
> under Apache 2.0. No kidding.
>
> All you have to do is have some way for 2.0 to 'fake' the
> old BUFF calls with a 'filter wrapper' around that
> (simple) module. You might even be able to do it by
> 'ifdef'ing the old BUFF calls with new MACRO calls
> but that would require a re-compile.
>
> This would require some ( a lot? ) of code in the core
> module loader/runner that isn't there right now but
> IT COULD BE DONE.
>
> If Microsoft can carry their DLLs forward through 3
> major architecture changes... you can do the same.
>
> It just takes adding the right 'smarts' to the Server itself.
>
> ----
> FACT?: Whatever the target codebase... it's become nearly
> impossible to get patches reviewed.
> ----
>
> This is obviously going to be addressed and will
> probably be the MAJOR discussion topic in Las Vegas.
>
> Hooray!
>
> Whatever can be done to RENEW interest in Apache
> development ( see all of above ) and just generally
> crank the forum volume back up will probably help.
>
> Yours...
> Kevin Kiley
>
> PS: FWIW...
>
> > scrappy@hub.org wrote...
> >>
> >> > and mod_* support ... last I checked, mod_gzip is still Apache1-only,
> >>
> >> mod_gzip?  Try mod_deflate, it is included with apache 2:
> >> http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
> >
> > Didn't know about this ... will look at it, thanks ...
>
> mod_gzip was actually written FIRST for Apache 2.0 sometime
> in the distant past when there was a ( false ) rumor
> that 2.0 might actually be nearing a release. It
> worked fine against the brand-new 2.0 filtering APIs and might
> have been the first module written to use them, even before
> mod_include was re-worked.
>
> When the rumor turned out to be false and that it might be more
> than a YEAR before 2.0 got anywhere near a release... I simply
> BACK-PORTED it to Apache 1.3 because I didn't want to wait
> that long for people to start using it.
>
> So mod_gzip has ALWAYS been available for 2.0... even long
> before 2.0 was finished. Porting it BACK to 1.3 was an after-thought.
>
> mod_gzip is officially maintained ( by many others now,
> and NOT ME ) at SOURCEFORGE...
>
> http://sourceforge.net/projects/mod-gzip/
>
> ( That's a DASH in mod-gzip part of the URI and not an UNDERSCORE )
>
> or somebody ( don't know who ) also added it to FRESHMEAT...
>
> http://freshmeat.net/projects/mod_gzip/
>
> ( Now it really is an UNDERSCORE in 'mod_gzip' part of URI )
>
> The 2.0 version(s) of mod_gzip are also found at...
>
> http://www.gknw.com/development/apache/httpd-2.0/unix/modules/
>
> Just grab mod_gzip-2.0.40.tar.gz
>
> ...and right here in Apache's own code archives.
>
> Complete working version(s) of mod_gzip for Apache 2.0 were
> donated to ASF a long time ago.
>
> I will be the first to tell you that there is functionally
> no difference between mod_gzip and mod_deflate. The only
> difference you will find is that mod_gzip still has many
> more options for 'including' or 'excluding' things from
> being compressed in order to deal with the 'realities'
> of modern and legacy User-Agents.
>
>
>
>
>
>
>
>
>
>
>
>
>
>


Mime
View raw message