Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: TOKILEY@aol.com
Message-ID: <143.1c4231ac.2ce9cd3d@aol.com>
Date: Mon, 17 Nov 2003 02:05:33 EST
Subject: Re: consider reopening 1.3
To: dev@httpd.apache.org
CC: scrappy@hub.org, TOKILEY@aol.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


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.