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

Re: consider reopening 1.3

2003-11-17 Thread Kyle Hamilton

bravo!
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
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

Re: consider reopening 1.3


Last benchmarks I have currently are quite old.

I think the last time I ( just a USER of Apache ) did
any serious benchmarking was 2.0.40 or something...
but the results were right inline with what Rasmus
just posted. 

Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork.

If I get some time off from my 'real' job in the next little while
I will try and get you some benchmarks... but if you read my
last message you will see that it says...

 FACT?: - That's a QUESTION MARK there.

 - 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.

That's kinda parta the problem right at the moment, isn't it?

Apache 2.0 has been out for almost 2 years and nobody
seems to be sure WHAT the real performance numbers are???

That's just an indication of how bad the lethargy has become
and/or how piss-poor the rollout follow-up on 2.0 has been.

Later...
Kevin


In a message dated 11/17/2003 2:01:13 AM Central Standard Time, [EMAIL PROTECTED] writes:


* [EMAIL PROTECTED] wrote:

 --
 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.
 --

Do you have a supporting benchmark available? Benchmarking a PHP script as
Rasmus did does not express anything about the httpd.

Please don't continue to distribute misleading information again and again
you know nothing about.

nd

Re: consider reopening 1.3


Fantastic!

So Rasmus has just uncovered some 'other' problem then
which means (only) mod_perl is a pig on 2.0 or something?

I guess that's better than the core being the problem.

I'd like to see this get put to bed once and for all and eliminate
it from the 2.0 migration discussion(s).

Got any real numbers?

What if sendfile was added to 1.3? I wonder how it
would all stack up then?

Last time I checked... 'sendfile' was not available on all platforms.
What would the numbers look like on those platforms?

Later...
Kevin


In a message dated 11/17/2003 3:02:24 AM Central Standard Time, [EMAIL PROTECTED] writes:


On Mon, Nov 17, 2003 at 02:05:33AM -0500, [EMAIL PROTECTED] wrote:
 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.

Not for me it's not. Especially with sendfile.

-- 
Colm MacCárthaigh Public Key: [EMAIL PROTECTED]

Re: consider reopening 1.3

2003-11-17 Thread Matthieu Estrade

You are right, apache 2.0 pre fork is  apache 1.3 prefork...
But one nice feature of apache 2.0 is to provide other mpm more powerfull.
worker mpm is  apache 1.3.
If you look all benchmark of web server, you will see that all are now 
providing threaded architectures because it's more stable and faster.
Did you see all speed benchmark ? for example IIS 6 is really faster 
than apache 1.3 and a bit than threaded mpm of apache 2.0.
Apache 2.0 is able to run on old plateform not using threaded mpm and 
also to run faster on the lastest plateform using threads...

I also read here that companies prefer buy load balancer than take a 
faster web server... it's right in 50% of them, but not for the 50% of 
the others who want load balancer + webserver performance.
And what about companies not able to buy load balancer, running a 
webserver for many services, (i think to all these companies selling 
packaged and hosted webserver) and using a basic linux distribution, or 
a BSD distrib ? i think they could be happy to use the real power of 
threads than stay on Apache 1.3. (which one of them not want to announce 
more power, and more security ?).
Apache is fighting against webserver now providing powerfull features 
_ONLY_ based on threaded architectures.
And i think in the future it will be based more and more on this, if 
not, why all unix kernel are working and now providing thread lib and 
function more and more powerfull ???

What about all this new features in Apache 2.0 which is oriented (IMHO) 
for web application, what about the security of them ? the entire and 
easy control of input and output data due to filters ?
Apache 1.3 is working fine yes... but did you see all new features 
provided by others webserver, based on apps, apps security, and apps speed ?
Apache 2.0 is designed to give a solid answer to this, on all actual and 
future needs. it's just asking to become more and more stable.

For me, Apache 1.3 will become more and more stopped to give place to a 
more powerfull solution, able to run latest applications and features.

(I am benchmarking the speed of Apache 2.0 for 1 years and an half now, 
with a special and dedicated request injector architecture able to 
simulate connexions, hits, auth etc...
And yes, worker mpm is faster than apache 1.3. )

In Apache 2.0 I trust :p

regards,
Matthieu
[EMAIL PROTECTED] wrote:

Last benchmarks I have currently are quite old.

I think the last time I ( just a USER of Apache ) did
any serious benchmarking was 2.0.40 or something...
but the results were right inline with what Rasmus
just posted.
Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork.

If I get some time off from my 'real' job in the next little while
I will try and get you some benchmarks... but if you read my
last message you will see that it says...
 FACT?:  - That's a QUESTION MARK there.

 - 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.
That's kinda parta the problem right at the moment, isn't it?

Apache 2.0 has been out for almost 2 years and nobody
seems to be sure WHAT the real performance numbers are???
That's just an indication of how bad the lethargy has become
and/or how piss-poor the rollout follow-up on 2.0 has been.
Later...
Kevin
In a message dated 11/17/2003 2:01:13 AM Central Standard Time, 
[EMAIL PROTECTED] writes:


* [EMAIL PROTECTED] wrote:

 --
 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.
 --
Do you have a supporting benchmark available? Benchmarking a PHP 
script as
Rasmus did does not express anything about the httpd.

Please don't continue to distribute misleading information again and 
again
you know nothing about.

nd

Re: consider reopening 1.3

2003-11-17 Thread Colm MacCarthaigh

On Mon, Nov 17, 2003 at 04:40:02AM -0500, [EMAIL PROTECTED] wrote:
 Got any real numbers?

Completely unconfigured, out of the box configs;

Apache 1.3.29;

Concurrency Level:  100
Time taken for tests:   2.54841 seconds
Complete requests:  1000
Failed requests:0
Write errors:   0
Total transferred:  1883090 bytes
HTML transferred:   1466192 bytes
Requests per second:486.66 [#/sec] (mean)
Time per request:   205.484 [ms] (mean)
Time per request:   2.055 [ms] (mean, across all concurrent
requests)
Transfer rate:  894.47 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   1.8  0  13
Processing:17  193  38.7196 297
Waiting:   17  192  38.7196 296
Total: 23  194  37.8196 297

Percentage of the requests served within a certain time (ms)
  50%196
  66%201
  75%206
  80%209
  90%223
  95%252
  98%272
  99%280
 100%297 (longest request)

Apache 2.0.48 (using prefork):

Concurrency Level:  100
Time taken for tests:   1.110512 seconds
Complete requests:  1000
Failed requests:0
Write errors:   0
Total transferred:  1909712 bytes
HTML transferred:   1460368 bytes
Requests per second:900.49 [#/sec] (mean)
Time per request:   111.051 [ms] (mean)
Time per request:   1.111 [ms] (mean, across all concurrent
requests)
Transfer rate:  1678.51 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:03   3.2  3  13
Processing:21  100  14.1103 142
Waiting:3   96  14.2100 142
Total: 32  103  11.9106 143

Percentage of the requests served within a certain time (ms)
  50%106
  66%107
  75%107
  80%108
  90%109
  95%110
  98%114
  99%123
 100%143 (longest request)

That's completely unconfigured. Apache 2 is *much* more configurable,
and it's possible to make things much faster. It's not just faster,
it's capable of scaling much better. Two weeks ago I was sustaining
8,000 simultaneous connections and throughing out a about 300 Meg
of traffic. On the same hardware, 1.3 would never get close to that.
I used to get problems when dealing with a few hundred connections.

And before you ask; pre-fork. Btw, it's not as if you can just
disregard the other mpm's. They exist, and they are much faster
again than prefork. You can't just ignore progress because it
doesn't work on every platform.

There are other ways in which 2.0 is much better, mod_*_cache are good 
examples of how it's possible for admins to serve requests a lot faster, 
especially if they have slow disks and so on. 

 Last time I checked... 'sendfile' was not available on all platforms.
 What would the numbers look like on those platforms?

Much much much better. I turn off sendfile on purpose, because TCP
checksum offloading problems with my Gigabit NIC's means I can't use
it for IPv6. 

The friday before last, I was shipping 440Megabit's of traffic from one 
machine using httpd. That was using pre-fork, without sendfile. The notion 
that 2.0 does not outperform 1.3 is laughable, it does.

Now it may underperform it in some configurations, and a lot of people
report that they see slowdown with dynamic content, especially php,
but that's not the same thing as saying 2.0 is slower. I'm telling you,
it's certainly not in my configuration.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]

Re: consider reopening 1.3


 You are right, apache 2.0 pre fork is  apache 1.3 prefork...

Maybe. Maybe not. My 'FACT?:' header had a QUESTION MARK there.

Just in the last 4 or 5 messages on this thread the actual
reality has become even more obfuscated.

Rasmus seems to be saying it's a pig... but maybe he's 
simply uncovered a serious I/O problem in mod_perl 
or something other than the core itself.

Colm says the opposite.

I DON'T KNOW what the REAL story is.

Maybe nobody does. Nobody's bothered to find out for sure.

But wouldn't it be nice to know.. since this product has
more of a monopoly in it's target market than even 
Microsoft does in any of theirs?

To this day ( almost 2 years after the relase of 2.0 ) no one
has done any serious benchmarking... not even Covalent.
If they have... I've never seen it. URI?

All I know is that last time I (personally) tested Apache 2.0 
pre-fork against Apache 1.3 pre-fork the 'new' version was
losing hands-down as compared to the 'old' version.

'sendfile' doesn't do jack-squat for you if have a platform that
doesn't even fully support it and/or when the responses are 
dynamic and not static 'files'... which is more and more the
reality these days.

Your other points are WELL TAKEN.

I don't think anyone would say that there should NOT
be an MPM for Apache. 

If you have Natvie threads ( Windows ) or 3rd party threads ( UNIX )
then at least you have options.

If you have FreeBSD you are still kinda screwed but I'm sure
SOMEONE is going to fix that.

In the meantime... while all this is getting hashed out...
the subject of the thread is 'consider reopening 1.3'.

Whatever else is going on with 2.0... I say +1 to that.

Personally... I've always wondered how fast 1.3 could be
with full 'sendfile'.

Later...
Kevin


In a message dated 11/17/2003 4:09:37 AM Central Standard Time, [EMAIL PROTECTED] writes:


You are right, apache 2.0 pre fork is  apache 1.3 prefork...
But one nice feature of apache 2.0 is to provide other mpm more powerfull.

worker mpm is  apache 1.3.
If you look all benchmark of web server, you will see that all are now 
providing threaded architectures because it's more stable and faster.
Did you see all speed benchmark ? for example IIS 6 is really faster 
than apache 1.3 and a bit than threaded mpm of apache 2.0.
Apache 2.0 is able to run on old plateform not using threaded mpm and 
also to run "faster" on the lastest plateform using threads...

I also read here that companies prefer buy load balancer than take a 
faster web server... it's right in 50% of them, but not for the 50% of 
the others who want load balancer + webserver performance.
And what about companies not able to buy load balancer, running a 
webserver for many services, (i think to all these companies selling 
packaged and hosted webserver) and using a basic linux distribution, or 
a BSD distrib ? i think they could be happy to use the real power of 
threads than stay on Apache 1.3. (which one of them not want to announce 
more power, and more security ?).
Apache is fighting against webserver now providing powerfull features 
_ONLY_ based on threaded architectures.
And i think in the future it will be based more and more on this, if 
not, why all unix kernel are working and now providing thread lib and 
function more and more powerfull ???

What about all this new features in Apache 2.0 which is oriented (IMHO) 
for web application, what about the security of them ? the entire and 
easy control of input and output data due to filters ?
Apache 1.3 is working fine yes... but did you see all new features 
provided by others webserver, based on apps, apps security, and apps speed ?
Apache 2.0 is designed to give a solid answer to this, on all actual and 
future needs. it's just asking to become more and more stable.

For me, Apache 1.3 will become more and more stopped to give place to a 
more powerfull solution, able to run latest applications and features.

(I am benchmarking the speed of Apache 2.0 for 1 years and an half now, 
with a special and dedicated request injector architecture able to 
simulate connexions, hits, auth etc...
And yes, worker mpm is faster than apache 1.3. )

In Apache 2.0 I trust :p

regards,
Matthieu


[EMAIL PROTECTED] wrote:


 Last benchmarks I have currently are quite old.

 I think the last time I ( just a USER of Apache ) did
 any serious benchmarking was 2.0.40 or something...
 but the results were right inline with what Rasmus
 just posted.

 Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork.

 If I get some time off from my 'real' job in the next little while
 I will try and get you some benchmarks... but if you read my
 last message you will see that it says...

  FACT?: - That's a QUESTION MARK there.

  - 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

Re: consider reopening 1.3

2003-11-17 Thread Henning Brauer

On Sun, Nov 16, 2003 at 05:02:12PM -0800, Rasmus Lerdorf wrote:
 And a threaded mpm is just not an option.  Most humans 
 are simply not smart enough to write threadsafe code.

this is an interesting point.
I believe the moving towards threading is wrong.
I also find apache2 strongly suspective for the simple size. 1.3 is 
already bad, but the code size of 2.0 scares me. and honestly, I don't 
care for windows or netware support.
what remains is a IMHO overcomplicated architecture with much too much 
code, which makes it hard to audit, and gives no benefit to our users.
I don't see me importing apache2 into the OpenBSD tree anytime soon. 
honestly, I don't see that at all.

-- 
Henning Brauer, BS Web Services, http://bsws.de
[EMAIL PROTECTED] - [EMAIL PROTECTED]
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

Re: consider reopening 1.3


Hi Colm...

Slainte!...
Cead mile failte romhat!
Go raibh maith agat!

Wow... I believe everything you are saying... and
please don't take this the wrong way... but I'm not
sure a test that only runs for 1.1 second and 1000
requests with 100 clients being launched ( on the
same machine? ) is a good way to get accurate results
especially in the TPS ( Transactions Per Second )
numbers. The rounding errors alone could be huge
with so little time on the clock.

Try same test for a reasonable amount of TIME and
see if it's any different.

Rasmus recent benchmark shows the EXACT 
OPPOSITE and I think you have certainly just proved
that something is seriously wrong with THAT test...
but I'm not sure yours is the end-all be-all proof either.

When I get the chance... I'll run the same ( 6 hour )
benchmark against 2.0.47 that I did sometime back
for 2.0.40 and see what that says.

At that time... I did the same 'out of the box' thing
you just did and got the EXACT OPPOSITE results.
Apache 2.0 prefork was about twice as SLOW as
1.3 prefork... not twice as fast.

Man, this is confusing.

( Pionta Guiness le do thoil... fer sure )

Later... ( Slainte )...
Kevin

In a message dated 11/17/2003 4:17:57 AM Central Standard Time, [EMAIL PROTECTED] writes:



On Mon, Nov 17, 2003 at 04:40:02AM -0500, [EMAIL PROTECTED] wrote:
 Got any real numbers?

Completely unconfigured, out of the box configs;

Apache 1.3.29;

Concurrency Level: 100
Time taken for tests: 2.54841 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 1883090 bytes
HTML transferred: 1466192 bytes
Requests per second: 486.66 [#/sec] (mean)
Time per request: 205.484 [ms] (mean)
Time per request: 2.055 [ms] (mean, across all concurrent
requests)
Transfer rate: 894.47 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 0 0 1.8 0 13
Processing: 17 193 38.7 196 297
Waiting: 17 192 38.7 196 296
Total: 23 194 37.8 196 297

Percentage of the requests served within a certain time (ms)
 50% 196
 66% 201
 75% 206
 80% 209
 90% 223
 95% 252
 98% 272
 99% 280
100% 297 (longest request)

Apache 2.0.48 (using prefork):

Concurrency Level: 100
Time taken for tests: 1.110512 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 1909712 bytes
HTML transferred: 1460368 bytes
Requests per second: 900.49 [#/sec] (mean)
Time per request: 111.051 [ms] (mean)
Time per request: 1.111 [ms] (mean, across all concurrent
requests)
Transfer rate: 1678.51 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 0 3 3.2 3 13
Processing: 21 100 14.1 103 142
Waiting: 3 96 14.2 100 142
Total: 32 103 11.9 106 143

Percentage of the requests served within a certain time (ms)
 50% 106
 66% 107
 75% 107
 80% 108
 90% 109
 95% 110
 98% 114
 99% 123
100% 143 (longest request)

That's completely unconfigured. Apache 2 is *much* more configurable,
and it's possible to make things much faster. It's not just faster,
it's capable of scaling much better. Two weeks ago I was sustaining
8,000 simultaneous connections and throughing out a about 300 Meg
of traffic. On the same hardware, 1.3 would never get close to that.
I used to get problems when dealing with a few hundred connections.

And before you ask; pre-fork. Btw, it's not as if you can just
disregard the other mpm's. They exist, and they are much faster
again than prefork. You can't just ignore progress because it
doesn't work on every platform.

There are other ways in which 2.0 is much better, mod_*_cache are good 
examples of how it's possible for admins to serve requests a lot faster, 
especially if they have slow disks and so on. 

 Last time I checked... 'sendfile' was not available on all platforms.
 What would the numbers look like on those platforms?

Much much much better. I turn off sendfile on purpose, because TCP
checksum offloading problems with my Gigabit NIC's means I can't use
it for IPv6. 

The friday before last, I was shipping 440Megabit's of traffic from one 
machine using httpd. That was using pre-fork, without sendfile. The notion 
that 2.0 does not outperform 1.3 is laughable, it does.

Now it may underperform it in some configurations, and a lot of people
report that they see slowdown with dynamic content, especially php,
but that's not the same thing as saying 2.0 is slower. I'm telling you,
it's certainly not in my configuration.

-- 
Colm MacCárthaigh Public Key: [EMAIL PROTECTED]

Re: consider reopening 1.3

2003-11-17 Thread Colm MacCarthaigh

On Mon, Nov 17, 2003 at 06:00:09AM -0500, [EMAIL PROTECTED] wrote:
 Hi Colm...
 
 Slainte!...
 Cead mile failte romhat!
 Go raibh maith agat!

Agus tú féin a cháirde, chaitfidh mé rá b'éidir gurb seo on 
t-aon deis a bhéis gam cumarsáid le Gaeilgeoir so comh-théacs 
seo, ach mar a deartaí áfach - Is annamh is íontach. 

Actually I must get round to tranlating the errordocs ;)

 Wow... I believe everything you are saying... and
 please don't take this the wrong way... but I'm not
 sure a test that only runs for 1.1 second and 1000
 requests with 100 clients being launched ( on the
 same machine? ) is a good way to get accurate results
 especially in the TPS ( Transactions Per Second )
 numbers. The rounding errors alone could be huge
 with so little time on the clock.

Saves me time though ;) It's a quick way to get numbers - and I
was trying to be fairer to 1.3, but with 100,000 - 

Apache 2 prefork:

Concurrency Level:  100 
Time taken for tests:   100.192136 seconds
Complete requests:  10  
Failed requests:0   
Write errors:   0
Total transferred:  190466640 bytes
HTML transferred:   145650960 bytes
Requests per second:998.08 [#/sec] (mean)
Time per request:   100.192 [ms] (mean)
Time per request:   1.002 [ms] (mean, across all concurrent
requests)
Transfer rate:  1856.45 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:0   44  12.8 47 134
Processing:22   54  15.7 51 305
Waiting:2   49  15.2 47 304
Total: 29   99   6.6 98 314

Percentage of the requests served within a certain time (ms)
  50% 98
  66% 99
  75%100
  80%100
  90%104
  95%110
  98%117
  99%126
 100%314 (longest request)

Apache 1.3: same hardware

First try:

lasaire:/usr/local/apache# ../apache2/bin/ab -c 100 -n 10 http://samhain:8080/
This is ApacheBench, Version 2.0.40-dev $Revision: 1.131 $ apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/

Benchmarking samhain (be patient)
apr_poll: The timeout specified has expired (70007)
Total of 4060 requests completed

Second attempt:

Concurrency Level:  100
Time taken for tests:   188.725417 seconds
Complete requests:  10
Failed requests:0
Write errors:   0
Total transferred:  187087890 bytes
HTML transferred:   145668432 bytes
Requests per second:529.87 [#/sec] (mean)
Time per request:   188.725 [ms] (mean)
Time per request:   1.887 [ms] (mean, across all concurrent
requests)
Transfer rate:  968.09 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:0   87  23.0 90 178
Processing: 4   99  25.3 97 751
Waiting:1   93  24.0 91 690
Total: 10  187   8.9186 847

Percentage of the requests served within a certain time (ms)
  50%186
  66%188
  75%189
  80%190
  90%194
  95%201
  98%206
  99%209
 100%847 (longest request)


And this benchmark is light compared to what we see as production
load. I could run the benchmarks into the many millions, but it's
not going to make a difference. 

 Rasmus recent benchmark shows the EXACT 
 OPPOSITE and I think you have certainly just proved
 that something is seriously wrong with THAT test...
 but I'm not sure yours is the end-all be-all proof either.

They're different tests, it's not uncommon for different tests
to have different results. The atomics around dynamic content
are very different from static, Apache 2.0 kicks 1.3 ass when
it comes to static content. When I migrate dynamic content to
2.0 I don't see the same improvment, but I do see some. Then
again, I'm a heavy user of suexec stype dymanic content rather
than modules.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]

Re: 1.3 Wishlist: (Was: Re: consider reopening 1.3)

2003-11-17 Thread Igor Sysoev

On Sun, 16 Nov 2003, Rasmus Lerdorf wrote:

 On Sun, 16 Nov 2003, Jim Jagielski wrote:
  So a useful topic is: What is *missing* in 1.3 that needs to be 
  addressed.
  What are the features/additions that the disenfranchised 1.3 developers
  want to add to 1.3...
 
 How about support for chunked compressed responses right in 
 src/main/buff.c where it belongs (given we don't have filters in Apache1)

There's mod_deflate module for Apache 1.3.x that patches buff.c and
compesses a response on the fly. It's available at http://sysoev.ru/en/


Igor Sysoev
http://sysoev.ru/en/

Re: consider reopening 1.3

2003-11-17 Thread Graham Leggett

[EMAIL PROTECTED] wrote:

--
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! ).
That statement is just ridiculous. There are many reasons why a person 
might upgrade to v2.0 - the new functionality offered by the filtering 
API (mod_cache, mod_deflate and friends), etc etc.

And from a performance perspective, I personally would not run a 
webserver on hardware that was too close to 100% utilised, so the 
performance problem is normally not a huge one in most cases.

Regards,
Graham
--

Re: consider reopening 1.3

[EMAIL PROTECTED] wrote:
 
 
 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?...
 

Still waiting to see what, exactly, people want to see
in 1.3 that isn't there... So far, we've had a small handful
of suggestions. It will be curious to see how many of those
are handled by 2.0...

But recall that it is the truth of things that everything has
a time to end. I'm not saying that it is the time for 1.3
to be put to bed (and I'm not saying that it's not) but it
will be one day. It happened with Apache 1.2. It happened
with PHP3. It'll happen soon with PHP4. It happened with
RH7. It happened with bind4 and bind8 and sendmail8.9, etc...
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

RE: consider reopening 1.3

Bill,

I've done some thinking about this - price/performance is only part of the
equation.

Someone needs to take a step back and see where Apache wants to *be* in two
years time. I agree with Jim that 1.x probably is just about done, it works,
people understand it and have ported their modules to it, and performance is
good enough. So that leaves you with 2.x The debate will rage on whether
it's faster than 1.x, but the benchmarking is a slippery slope and we've all
been down it at some time.

Personally I think you have to focus on the customer via market segment. The
super user who wants to play with Apache 2.x work out the kinks, port his
modules and really fine tune it. That's about 1/10 of 1% of your addressable
market. He is not going to pull this product into the mainstream market.

Therefore who is your classic Apache user and what does he want that he
can't get right now? Probably not much. Let me use mod_gzip as an example.
When we released it we were busy for about 4 months fixing it for the real
world i.e. with a ton of feedback. Since then (over 2 years) we haven't
touched it, why? Because it does all it needs to do and people are happy
with the status quo. How do we improve on that? While I'm sure we can come
up with a few ideas will people buy into it? I can't justify the resources
in this economy to find out.

Right now the status quo is prevailing with 1.x and 2.x is not a must
have. To prove my point look no further than Covalent. When money is on the
table the rules change. Covalent have not been able to monetize 2.x in the
way everyone thought it could be done. Therefore what has the current
management team done - change direction to the new focus of web application
management and security. Sure there's still a web server in their somewhere
but now there's a different agenda i.e. make money for the shareholders. 

So what would I do...


Apache 1.x  - mass market - status quo prevails - boring but stable

Apache 2.x  - tiny market - **risk takers only** - not stable enough,
tough to understand

So what's the differentiator that drives the next wave? Personally (my
opinion only guys) it's hardware. 64-bit is now here. There are only going
to be a few choices. Either Sun, AMD, PowerPC or Itanium. Sun has had 64-bit
for a long time and is already entrenched at the web edge. AMD adds CISC
compatibility with a hint of RISC. Upside is that it runs x86 code about 10%
faster than Pentium PC's. PowerPC is a different beast but runs Apache just
fine.

AMD, Sun, PowerPC handle between 1-4 instructions per cycle, Itanium (which
is a whole new architecture) handles 6-8 instructions per cycle. Bottom line
if you code it correctly Itanium is going to be the flat out winner in a
drag race. It also happens to run Apache fine and as you've seen from our
benchmarks you can really tune this box to do some real magic. That's a
differentiator. Up until now there has been one big problem with Itanium -
it costs too much. That's going to change. 

We're coming up to a new hardware cycle (technology adoption life cycle
TALC). Machines purchased in 1999 are going to be replaced and people will
move to 64-bit. Why because we all like new toys especially if they are
cheap. What we don't want is lots of hard work to port our apps. AMD has
made this easy and next year Intel will do the same thing for Itanium by
releasing btrans (binary translator) which will allow you to run all your
x86 apps at Xeon speeds on an Itanium. 

So what are we going to see - lots of cheap web edge processors and people
will start moving their apps etc over. So what's the opportunity for Apache.

My opinion only - optimize it for 64-bit. Focus 80% of your available
resources on Apache 1.x because it has such a HUGE user base. The remaining
20% of your resources should focus on 2.x

Why? Because it's still too darn difficult to move people's apps to the 2.x
architecture. They will continue to take the path of least resistance which
means hardware. If you want to drop 1.3 and focus on 1.4 then make it for
64-bit, because it gives you a hardware performance boost.

It's all about focus and market segmentation - Covalent just learned the
hard way, even with mod_compat to make your 1.x modules run in a 2.x
environment they couldn't sell something with a delta of over a 1,000
dollars over something that is free. So they switched gears and went in a
different direction.

Learn from what they did - you don't need to do the same but don't continue
doing what your doing, the message is too confusing.

So for Jim J...

1.3 Done12 million happy customers
1.4 64-bit  12 million potential customers

2.x Work in progressnot sure how many customers?

I know where I would go.

Regards,


Peter 









-Original Message-
From: Bill Stoddard [mailto:[EMAIL PROTECTED] 
Sent: Sunday, November 16, 2003 6:03 PM
To: [EMAIL PROTECTED]
Subject: Re: consider reopening 1.3

Peter J. Cranstone wrote:

 In today's

RE: consider reopening 1.3

To support my comments on cheap 64-bit computing see this link:
http://www.siliconvalley.com/mld/siliconvalley/7281990.htm

Sun, AMD announce plans for line of low-cost servers - 64-bit!

People will move Apache 1.x to this platform because there is virtually NO
migration cost (i.e. recoding modules etc) and they get a performance boost
and while replacing an aging infrastructure.

12 million user on the move - make it easy for them, buy a cheap AMD Opteron
and optimize and improve Apache 1.4 on that box.

Regards,


Peter


-Original Message-
From: Peter J. Cranstone [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 17, 2003 7:18 AM
To: [EMAIL PROTECTED]
Subject: RE: consider reopening 1.3

Bill,

I've done some thinking about this - price/performance is only part of the
equation.

Someone needs to take a step back and see where Apache wants to *be* in two
years time. I agree with Jim that 1.x probably is just about done, it works,
people understand it and have ported their modules to it, and performance is
good enough. So that leaves you with 2.x The debate will rage on whether
it's faster than 1.x, but the benchmarking is a slippery slope and we've all
been down it at some time.

Personally I think you have to focus on the customer via market segment. The
super user who wants to play with Apache 2.x work out the kinks, port his
modules and really fine tune it. That's about 1/10 of 1% of your addressable
market. He is not going to pull this product into the mainstream market.

Therefore who is your classic Apache user and what does he want that he
can't get right now? Probably not much. Let me use mod_gzip as an example.
When we released it we were busy for about 4 months fixing it for the real
world i.e. with a ton of feedback. Since then (over 2 years) we haven't
touched it, why? Because it does all it needs to do and people are happy
with the status quo. How do we improve on that? While I'm sure we can come
up with a few ideas will people buy into it? I can't justify the resources
in this economy to find out.

Right now the status quo is prevailing with 1.x and 2.x is not a must
have. To prove my point look no further than Covalent. When money is on the
table the rules change. Covalent have not been able to monetize 2.x in the
way everyone thought it could be done. Therefore what has the current
management team done - change direction to the new focus of web application
management and security. Sure there's still a web server in their somewhere
but now there's a different agenda i.e. make money for the shareholders. 

So what would I do...


Apache 1.x  - mass market - status quo prevails - boring but stable

Apache 2.x  - tiny market - **risk takers only** - not stable enough,
tough to understand

So what's the differentiator that drives the next wave? Personally (my
opinion only guys) it's hardware. 64-bit is now here. There are only going
to be a few choices. Either Sun, AMD, PowerPC or Itanium. Sun has had 64-bit
for a long time and is already entrenched at the web edge. AMD adds CISC
compatibility with a hint of RISC. Upside is that it runs x86 code about 10%
faster than Pentium PC's. PowerPC is a different beast but runs Apache just
fine.

AMD, Sun, PowerPC handle between 1-4 instructions per cycle, Itanium (which
is a whole new architecture) handles 6-8 instructions per cycle. Bottom line
if you code it correctly Itanium is going to be the flat out winner in a
drag race. It also happens to run Apache fine and as you've seen from our
benchmarks you can really tune this box to do some real magic. That's a
differentiator. Up until now there has been one big problem with Itanium -
it costs too much. That's going to change. 

We're coming up to a new hardware cycle (technology adoption life cycle
TALC). Machines purchased in 1999 are going to be replaced and people will
move to 64-bit. Why because we all like new toys especially if they are
cheap. What we don't want is lots of hard work to port our apps. AMD has
made this easy and next year Intel will do the same thing for Itanium by
releasing btrans (binary translator) which will allow you to run all your
x86 apps at Xeon speeds on an Itanium. 

So what are we going to see - lots of cheap web edge processors and people
will start moving their apps etc over. So what's the opportunity for Apache.

My opinion only - optimize it for 64-bit. Focus 80% of your available
resources on Apache 1.x because it has such a HUGE user base. The remaining
20% of your resources should focus on 2.x

Why? Because it's still too darn difficult to move people's apps to the 2.x
architecture. They will continue to take the path of least resistance which
means hardware. If you want to drop 1.3 and focus on 1.4 then make it for
64-bit, because it gives you a hardware performance boost.

It's all about focus and market segmentation - Covalent just learned the
hard way, even with mod_compat to make your 1.x modules run in a 2.x
environment they couldn't sell

Re: consider reopening 1.3

2003-11-17 Thread Igor Kovalenko

 On Sun, 16 Nov 2003, Jeff Trawick wrote:
  Too bad all these supposedly-disenfranchised people aren't around to
review 1.3
  fixes.  1.3 would be healthier if they were.

 And it is the reason for why they are not around that is in question here.
 Why wouldn't there be plenty of hackers around for a piece of software
 used to widely?  Blaming the hackers seems a bit shortsighted.  Have a
 look at the environment we have given them to operate in and at some of
 the responses over the years people have gotten when they suggested new
 features for 1.3.


I am just lurking here really... but a while back I did try to post some
patches dealing with QNX support to both Apache and PHP. In my humble
opinion, there was a world of difference in attitude that I have encountered
in those two projects.

The attitude of PHP folks was 'you can commit patches so long as you stand
by to fix anything you break right away' (hey Rasmus :). The very atmosphere
was rather welcoming. Hell, they even put me onto the credits page at the
time and I did not even think myself that I did that much.

With the Apache, you don't get to commit. Which is fine too, so long as
someone is managing patch submissions. I got one initial reply that objected
the patch on the grounds that were arguable. Then I followed up with a
refined patch, but never got any more replies, even after posting it 3
times.

So, perhaps that patch was not that interesting to the core developers.
Understandable, but then almost every minor patch is not so interesting to
the majority. If you cut them all for that reason, you get the situation
that you have now.

Then I should note, situation was not always the same. Years before (that
is, before 2.0 branch) I did another patch of that sort and it went in just
fine. Again, I can quite understand the desire of core developers to
concentrate on the new branch, rather than do gruesome work on that
old-hopelessly-obsolete-code-that-you-do-not-like-anymore. The only trouble
really is that 2.0 branch has failed to interest that many users. Why is a
big question, but I think from end-user perspective one major reason is that
it simply does not add much that's really worth moving. Architectural
elegance is important to developers (and there is nothing I personally like
more) but end users tend to treat it like their cars. Most of them don't
ever look under the hood. Feel free to laugh, but if you want users 'pay'
(that is take pain of moving) for that new wonderful engine in the 2.0, you
need to show them a carrot in form of those heated memory seats,
self-dimming mirrors, rainsensitive wipers, et cetera. Or at least it should
drive faster, which (last time I checked) it did not.

Regards,
-- igor

Antw: RE: consider reopening 1.3

2003-11-17 Thread Andre Schild

People will move Apache 1.x to this platform because there is virtually NO
migration cost (i.e. recoding modules etc) and they get a performance boost
and while replacing an aging infrastructure.

12 million user on the move - make it easy for them, buy a cheap AMD Opteron
and optimize and improve Apache 1.4 on that box.
Today perhaps, but tomorrow with IPv6 ?

André

aarboard ag
internet - networks - screenprint design - multimedia
Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland)
Phone +41 32 332 9714 - Fax +41 32 332 9715
www.aarboard.ch - [EMAIL PROTECTED]

RE: Antw: RE: consider reopening 1.3

Oh yes - forgot about v6... that's a must have for Apache. Is it available
for 1.x? If not that would be the first feature to add.

Peter

-Original Message-
From: Andre Schild [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 17, 2003 10:07 AM
To: [EMAIL PROTECTED]
Subject: Antw: RE: consider reopening 1.3

People will move Apache 1.x to this platform because there is virtually NO
migration cost (i.e. recoding modules etc) and they get a performance boost
and while replacing an aging infrastructure.

12 million user on the move - make it easy for them, buy a cheap AMD
Opteron
and optimize and improve Apache 1.4 on that box.
Today perhaps, but tomorrow with IPv6 ?

André

aarboard ag
internet - networks - screenprint design - multimedia
Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland)
Phone +41 32 332 9714 - Fax +41 32 332 9715
www.aarboard.ch - [EMAIL PROTECTED]

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Colm MacCarthaigh

On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote:
 Oh yes - forgot about v6... that's a must have for Apache. Is it available
 for 1.x? If not that would be the first feature to add.

The KAME project has IPv6 patches for 1.3.* at

ftp://ftp.kame.net/pub/kame/misc/

they work on KAME (ie *BSD) stacks but have issues on platforms without 
INET6_V6ONLY support (but just about work). linux.or.jp used to maintain 
an alternative patch with v6 support, but that's since gone.

The patches are all truly horrendous. APR has a much better model for
all of this.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Bill Stoddard

Colm MacCarthaigh wrote:

On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote:

Oh yes - forgot about v6... that's a must have for Apache. Is it available
for 1.x? If not that would be the first feature to add.


The KAME project has IPv6 patches for 1.3.* at

	ftp://ftp.kame.net/pub/kame/misc/

they work on KAME (ie *BSD) stacks but have issues on platforms without 
INET6_V6ONLY support (but just about work). linux.or.jp used to maintain 
an alternative patch with v6 support, but that's since gone.

The patches are all truly horrendous. APR has a much better model for
all of this.
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows 
specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would 
probably see rapid uptake. I can't say that thrills me but it's probably true...

Bill

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Rasmus Lerdorf

On Mon, 17 Nov 2003, Bill Stoddard wrote:
 Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) 
 with all the Windows 
 specific code stripped out and source compatability (to the extent possible) with 
 Apache 1.3 modules would 
 probably see rapid uptake. I can't say that thrills me but it's probably true...

Not sure why providing useful software wouldn't thrill you.  I think the
point here is that someone is eventually going to do this.  Would be nicer
to have it under our control than have it leave the ASF.

-Rasmus

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Glenn

On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
 Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit 
 support) with all the Windows specific code stripped out and source 
 compatability (to the extent possible) with Apache 1.3 modules would 
 probably see rapid uptake. I can't say that thrills me but it's probably 
 true...

+1

How can I help?  Break it into bite-sited tasks and I'll do some munching.
Thanks!
Glenn

Re: Antw: RE: consider reopening 1.3

Glenn wrote:
 
 On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
  Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit 
  support) with all the Windows specific code stripped out and source 
  compatability (to the extent possible) with Apache 1.3 modules would 
  probably see rapid uptake. I can't say that thrills me but it's probably 
  true...
 
 +1
 

Again, unless there is 100% binary compatibility, which I do NOT
see with 1.4, then *what* is the driver for 1.4 over 2.x??

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: Antw: RE: consider reopening 1.3

On Nov 17, 2003, at 1:31 PM, Bill Stoddard wrote:

Colm MacCarthaigh wrote:

On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote:
Oh yes - forgot about v6... that's a must have for Apache. Is it 
available
for 1.x? If not that would be the first feature to add.
The KAME project has IPv6 patches for 1.3.* at
	ftp://ftp.kame.net/pub/kame/misc/
they work on KAME (ie *BSD) stacks but have issues on platforms 
without INET6_V6ONLY support (but just about work). linux.or.jp used 
to maintain an alternative patch with v6 support, but that's since 
gone.
The patches are all truly horrendous. APR has a much better model for
all of this.
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 
bit support) with all the Windows specific code stripped out and 
source compatability (to the extent possible) with Apache 1.3 modules 
would probably see rapid uptake. I can't say that thrills me but it's 
probably true...

Once we break binary compatibility, and with the above definition of 1.4
I think that's a certainty, then I don't see the big reason for
a 1.4 over 2.0.
There's a big diff, IMO, between opening up development on 1.3
and trying to make 1.3 a 2.0-lite.

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Rasmus Lerdorf

On Mon, 17 Nov 2003, Jim Jagielski wrote:

 Glenn wrote:
  
  On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
   Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit 
   support) with all the Windows specific code stripped out and source 
   compatability (to the extent possible) with Apache 1.3 modules would 
   probably see rapid uptake. I can't say that thrills me but it's probably 
   true...
  
  +1
  
 
 Again, unless there is 100% binary compatibility, which I do NOT
 see with 1.4, then *what* is the driver for 1.4 over 2.x??

Why binary compatibility?  Recompiling a module is a hell of a lot easier 
than rewriting it.  

-Rasmus

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Bill Stoddard

Rasmus Lerdorf wrote:

On Mon, 17 Nov 2003, Bill Stoddard wrote:

Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows
specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would
probably see rapid uptake. I can't say that thrills me but it's probably true...

Not sure why providing useful software wouldn't thrill you.
Don't read too much into that comment. 1.3 is just so damn crufty in many respects as compared to 2.0 that it
offends my senses. But 1.3 has some significant strengths in its favor. 2.0.recent is pretty darn stable (at
least with the threaded MPM) and is backward compatable with binaries compiled with releases as early as
2.0.42. But the filter API in 2.0 is just horribly complex (IMHO) and takes a -lot- of effort to master.

Speculation.

In this economic environment (and perhaps this will turn out to be generally true from now on), companies are
not making investments in IT unless they can get a proven and almost immediate return on that investment.
Making the jump to Apache 2.0 -can- be a big investment (depending on how many custom/third party modules you
use) and that investment will not be made unless 2.0 enables some fundamental new business processes not
possible with 1.3. I would venture that most of those kinds of investments are being made in Java, .Net or PHP
application environments. Being able to eliminate 1 machine in 3 due to scalability improvements in 2.0
probably won't be a sufficient return on investment for most folks. A really kick-ass load balancing/active
fail-over feature in mod_proxy might generate some interest in 2.0 deployed in the DMZ (features like this are
significantly easier to implement in threaded webservers).

I think the
point here is that someone is eventually going to do this. Would be nicer
to have it under our control than have it leave the ASF.
You probably have a much better read on this than most of the folks here. I'd like to believe that ipv6,
threading and 64 bit support is the catalyst that will get many folks over to 2.0. Dunno tho...

-Rasmus
Bill

Re: Antw: RE: consider reopening 1.3

On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote:
In this economic environment (and perhaps this will turn out to be 
generally true from now on), companies are not making investments in 
IT unless they can get a proven and almost immediate return on that 
investment. Making the jump to Apache 2.0 -can- be a big investment 
(depending on how many custom/third party modules you use)
Most people with those big investments are using at least *some* 3rd 
party
modules. Having a 1.4 that is not binary compatible with 1.3
means that those 3rd party modules will need to be (at least)
re-compiled for 1.4. So they will need to worry about 1.3,
1.4 and 2.0 (and potentially 2.2)... That's an *awful* lot
to have people keep track of. I don't see companies out
there wanting to do that... they will maintain their 1.3
modules for awhile, and their 2.x ones, because it *is*
the next gen, but I think they would avoid 1.4 almost
totally.

Having 1.4 not be binary compatible with 1.3 severely limits its
usefulness to those exact people that it's supposed to be
helping.

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Rasmus Lerdorf

On Mon, 17 Nov 2003, Jim Jagielski wrote:
 On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote:
 
  In this economic environment (and perhaps this will turn out to be 
  generally true from now on), companies are not making investments in 
  IT unless they can get a proven and almost immediate return on that 
  investment. Making the jump to Apache 2.0 -can- be a big investment 
  (depending on how many custom/third party modules you use)
 
 Most people with those big investments are using at least *some* 3rd 
 party
 modules. Having a 1.4 that is not binary compatible with 1.3
 means that those 3rd party modules will need to be (at least)
 re-compiled for 1.4. So they will need to worry about 1.3,
 1.4 and 2.0 (and potentially 2.2)... That's an *awful* lot
 to have people keep track of. I don't see companies out
 there wanting to do that... they will maintain their 1.3
 modules for awhile, and their 2.x ones, because it *is*
 the next gen, but I think they would avoid 1.4 almost
 totally.
 
 Having 1.4 not be binary compatible with 1.3 severely limits its
 usefulness to those exact people that it's supposed to be
 helping.

As someone working in a company like that, I can tell you definitively 
that this is not true.  At least not here at the biggest web company in 
the world.

-Rasmus

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Andr Malo

* Rasmus Lerdorf [EMAIL PROTECTED] wrote:

 As someone working in a company like that, I can tell you definitively 
 that this is not true.  At least not here at the biggest web company in 
 the world.

*shrug*
Big or not, if it's the only one, it can develop the stuff it needs itself. I
personally don't see the need to do the dirty work for the biggest web company
in the world.

nd

Re: Antw: RE: consider reopening 1.3

On Nov 17, 2003, at 3:17 PM, Rasmus Lerdorf wrote:
As someone working in a company like that, I can tell you definitively
that this is not true.  At least not here at the biggest web company in
the world.
-Rasmus


Well, I can certainly say that with respect to many, many of
the clients I've worked with, it most certainly *is* the case.
Not having a WebLogic or WebSphere DSO, for example, puts 'em
in a world of hurt. Big time.
Look at the impact of not having 2.0 modules severely
limited the acceptance of 2.0. Not having 1.4 modules
will most certainly do the same*. If 1.4 == 1.3,
binary-wise, then it's a non-issue; if not, it's
a *major* issue.
* Yes, part of the delay was due to porting, which
  may not be one with 1.4. But we are *still* talking
  about distribution, support, etc.. of a load of
  modules.

Re: Antw: RE: consider reopening 1.3

2003-11-17 Thread Graham Leggett

Jim Jagielski wrote:

Look at the impact of not having 2.0 modules severely
limited the acceptance of 2.0. Not having 1.4 modules
will most certainly do the same*. If 1.4 == 1.3,
binary-wise, then it's a non-issue; if not, it's
a *major* issue.
* Yes, part of the delay was due to porting, which
  may not be one with 1.4. But we are *still* talking
  about distribution, support, etc.. of a load of
  modules.
In my experience, there are a lot of people out there who are running 
older versions of application servers, and upgrading to Apache v2.0 
would also mean upgrading to a newer application server release that 
supports Apache v2.0. The questions asked were invariably our app 
server (and associated dependancy on v1.3) works now, so why upgrade?.

Regards,
Graham
--

RE: Antw: RE: consider reopening 1.3

 then *what* is the driver for 1.4 over 2.x??

Right now I think it's unknown - but with some reasoned debate I think a
path will emerge. 

One other thought - Apache needs an enemy - and I mean this in the nicest
possible terms. Having been on the receiving end of the forums venom before
I know how everybody responds to a threat. With 66% market share and IIS the
only real threat, why does everyone come to work in the morning.

Larry Ellison said it best in Softwars - we pick our enemies very
carefully. I think this is an important point because it gives you focus
and reason for being.

2.x is adrift because there is no threat to it apart from apathy - so what
do you do to get the focus back on Apache? Personally I think the driver for
1.4 over 2.x is 64-bit because that's what people are going to be buying
next.

64-bit offers you three things:

1. Performance  1-4 IPC (instructions per cycle
2. Memory   4GB RAM
3. Security 

Sun, AMD, PowerPC all offer 1  2, Itanium offers you 6-8 IPC and some very
sophisticated security capabilities not found in any other chip
architecture. The downside of Itanium is it's perception in the market
place. Intel has done a terrible job of marketing it - however they do have
to protect the Pentium cash cow. This will all change sometime next year
with the btrans software which will give you Xeon performance for x86
programs running under the EPIC architecture.

Regards,



Peter



-Original Message-
From: Jim Jagielski [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 17, 2003 12:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Antw: RE: consider reopening 1.3

Glenn wrote:
 
 On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
  Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64
bit 
  support) with all the Windows specific code stripped out and source 
  compatability (to the extent possible) with Apache 1.3 modules would 
  probably see rapid uptake. I can't say that thrills me but it's probably

  true...
 
 +1
 

Again, unless there is 100% binary compatibility, which I do NOT
see with 1.4, then *what* is the driver for 1.4 over 2.x??

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: consider reopening 1.3

2003-11-17 Thread William A. Rowe, Jr.

At 07:32 PM 11/16/2003, Martin Kraemer wrote:

...only that tomorrow's apr might not be 100% compatible with today's.
Think of mod_ssl's and mod_dav's problem (the apache_1.3 version). They
must always add the apache_1.3 version number to their own version number
to describe the API they require. I would not like a
   apache-1.3.30-mod_ssl-2.8-20-apr-1.0.14 kind of delivery scheme.

Of course not.  mod_ssl's legacy goes to apache's legacy of breaking
compatibility early and often when it made things better/easier/simpler.

Apache 2.0 and APR 0.9 (soon 1.0) have avoided that approach as best
as possible (the poll API being the big exception.)

If you need apache 2.0 you need apr 0.9.  The API should be stable.

If you need apache 2.2 you will need apr 1.0 (or 1.1 if changes happen
to make 2.2 a possibility).

And within a given point release, apache 2.2 or apr 1.1, nothing will 
be broken.  That's the contract we are aiming for to avoid the very 
headache you describe above.

Bill

Re: consider reopening 1.3

2003-11-17 Thread Ben Hyde

+1

My only concern is that some scarce resource might be further 
dissipated by having multiple forks in progress.  I had some sympathy 
when 2.0 was trying to get started that 1.3 was a competitor for 
attention; I don't think that's a problem any more.  How audacious to 
be on 1.3?  Time will tell.  I see no need for a plan.

distcache (was RE: consider reopening 1.3)

2003-11-17 Thread Geoff Thorpe

On November 17, 2003 02:22 pm, Bill Stoddard wrote:
 application environments. Being able to eliminate 1 machine in 3 due to
 scalability improvements in 2.0 probably won't be a sufficient return
 on investment for most folks. A really kick-ass load balancing/active
 fail-over feature in mod_proxy might generate some interest in 2.0
 deployed in the DMZ (features like this are significantly easier to
 implement in threaded webservers).

Which reminds me, I must find someone who would be prepared to discuss our 
distributed session caching stuff (ww.distcache.org) for use with 
apache2/mod_ssl. Any takers? There are companies out there flogging 
pretty lame and expensive SSL load-balancers and if you're running more 
than one machine for https, you're almost obliged to go down that route 
even if it hurts all your rational sense. If scalability and 
architectural flexibility are part of the argument for 2.0, would it be 
advantageous to get distcache support included into apache? Mandrake and 
Redhat already have (optional) support in their SRPMS, FWIW.

The apache glue to the distcache API is a pretty small patch - an autoconf 
check plus an additional caching module/syntax in modules/ssl/. Use of 
the alternative session cache mode is via an alternative syntax to the 
SSLSessionCache configuration parameter. We upgraded the httpd patch to 
2.0.48 recently, but on the distcache side we are in the midst of trying 
to move the development branch to stable before chasing down 
integration too hard. Last time I looked into getting our patch into the 
upstream code, there were one or two fairly important unresolved bugs in 
distcache and apache's autoconf support for openssl/ssl-c needed quite a 
bit of reorganisation. I helped with the latter at that time, and we 
sorted out the remaining issues in distcache shortly after. So ... if 
there's anyone on the apache side who'd be prepared to look deeper into 
this and discuss integration with apache, please make contact with me off 
the list.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

Re: consider reopening 1.3

2003-11-17 Thread Sander Striker

On Sun, 2003-11-16 at 01:12, Glenn wrote:
 Ok, so Apache2 uptake is slower than desired for some (not all) on this
 list.  That's only logical given the success and therefore inertia to stay
 with Apache 1.3.  But there are more than a few other factors mentioned in
 recent threads that are contributing to Apache2 development stagnation.
 Ignore for a moment that vendors have only recently begun shipping Apache2
 as the default web server instead of Apache 1.3.  Stas pointed out some
 serious problems.  I reformulate them slightly differently here.
 
 - lack of clear leadership

That is a property of our development model.

  and even basic direction scratch-an-itch development is fine and good, but
  not in total chaos

The product is pretty mature.  The scratch-an-itch is mostly due to
bugreports, or own bug discovery.

 - cathedral development
   it appears that more than a few serious discussions have not happened
   on-list and instead happen on IRC or elsewhere (board rooms?) without
   apprising the list of what transpired.  (Or have there been absolutely
   no recent design discussions?)

This keeps comming back and back.  Yes, there are some loose discussions
on IRC sometimes.  But nothing is being hashed out there.  Most of it is
brought back to the list.
And at ApacheCon there are bound to be more discussions, given there
will be a large chunk of developers present.

[...]
 - insufficient (developer) documentation
   sure, there's the source, but it takes a lot longer to wrap ones head
   around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such.
   The barrier to entry is much higher; solid design documents would be
   infinitely helpful

This is being worked on.  Also, documentation patches are always more
than welcome...

 - dwindling community
   The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds
   with the rest of the world that relies on the venerable Apache 1.3

For a group of developers, whose time can be only spent once, it seems
no more than logical that they move on to the newest project.  Further,
the 1.3 tree is still in maintenance mode, and releases _do_ go out.

 - ...
 
 Whether or not you take issue with any of the above and can provide
 (quite reasonable) defenses, I think you'll agree that the problems
 above exist to some degree or another.  My driving point is that
 action needs to be taken to keep this community fresh and vibrant.

Sometimes taking some time off is considered a good action aswell.
It may even be the case that some of us are taking time off, just
to return fresh.

 Since there is not enough time for the project leaders to address these
 issues by themselves, the obvious answer is that there needs to be more
 people involved to help shoulder these tasks.

The pool of resources in the Open Source world is smaller as one thinks.
For instance, do a cross-reference between projects and notice names
coming back, over and over again.  If you really think that there are
people interested in this project, and even have the required skillset
to make a difference, why aren't they here, knocking down our doors?

 So where do we go from here?
 
 *** We need better patch management
 
 Some suggestions were made in recent threads; I won't relist them here,
 but they have my full +1 support.  I hope those at ApacheCon hash
 something great out.
 
 *** We need to get back many of the disenfranchised Apache 1.3 developers
 
 Killing Apache 1.3 is not a good option.  There is a strong business
 need in many places to stay with Apache 1.3.

Who said anything about killing?  The 1.3 tree is maintenance mode.
That means, bug fixes only, no new features.

 The better option is reopening the 1.3 tree.
 Release 1.4 and open a 1.5 dev tree, with the specific intent on
 having the 1.4 release eventually map _directly_ into a _seamless_
 upgrade to Apache 2.x, with very easy and clear directions for using
 a reverse proxy for those legacy 1.3 third-pary modules.)  While
 upgrading is not hard for developers, Apache is not a simple product.
 We need an even-better (tm) way to get users from There (Apache 1.3)
 to Here (Apache 2.x).  Yes, more trees are extra work, but this
 community is rapidly deteriorating without them.

Ahum, let me understand this correctly... You are suggesting that we
spread out our scarce resources over even more trees?  What do you
think will happen if we do that?  If there is more work to be done,
in basically the same time, by the same people, won't progress slow
down even more?

 *** We need to get more people using Apache 2.x

Now that seems like a wise remark.  This is happening step by step,
we're nicely ramping up.

 Apache 2.x is not going to get any better than it is now until more
 people start using it in the real world (outside the lab).  Welcoming
 back the 1.3 developers and aiding the transition is one piece.
 Making this forum more responsive (e.g. with better patch management)
 is another.  Project leadership

Re: consider reopening 1.3

2003-11-16 Thread Kyle Hamilton

Good Point I have noticed that there is still a large number of people that
use 1.3 and are upset cause they don't like whats going on with 2. I like
you idea we need to make it easyer for people to add to apache I find it
hard to even get people to do or help with little things. We have to many
indians and no chiefs we need to elect or maybe have some senior member sort
of take charge. Linux has torvlus so who will be our hero ;-)
-Kyle Hamilton
www.kylehamilton.net *blog*
www.kylehamilton.com *site in the works*
559-593-1210
- Original Message -
From: Glenn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 1:12 AM
Subject: consider reopening 1.3


 Ok, so Apache2 uptake is slower than desired for some (not all) on this
 list.  That's only logical given the success and therefore inertia to stay
 with Apache 1.3.  But there are more than a few other factors mentioned in
 recent threads that are contributing to Apache2 development stagnation.
 Ignore for a moment that vendors have only recently begun shipping Apache2
 as the default web server instead of Apache 1.3.  Stas pointed out some
 serious problems.  I reformulate them slightly differently here.

 - lack of clear leadership and even basic direction
   scratch-an-itch development is fine and good, but not in total chaos
 - cathedral development
   it appears that more than a few serious discussions have not happened
   on-list and instead happen on IRC or elsewhere (board rooms?) without
   apprising the list of what transpired.  (Or have there been absolutely
   no recent design discussions?)
 - patch management
   many patches posted to this list or the bug db languish in limbo.
   Very little happens until a core contributor decides to take over a
patch
   (more often than not it is more than simply shepherding it)
   Little feedback; it often feels like nobody's home to answer the
phone...
 - insufficient (developer) documentation
   sure, there's the source, but it takes a lot longer to wrap ones head
   around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such.
   The barrier to entry is much higher; solid design documents would be
   infinitely helpful
 - many new contributors are frustrated and discouraged
   see all of the above
   The voluble Kevin Kiley said it well:
   Make it EASY to contribute... not a nightmare.
 - dwindling community
   The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds
   with the rest of the world that relies on the venerable Apache 1.3
 - ...

 Whether or not you take issue with any of the above and can provide
 (quite reasonable) defenses, I think you'll agree that the problems
 above exist to some degree or another.  My driving point is that
 action needs to be taken to keep this community fresh and vibrant.

 Since there is not enough time for the project leaders to address these
 issues by themselves, the obvious answer is that there needs to be more
 people involved to help shoulder these tasks.

 So where do we go from here?

 *** We need better patch management

 Some suggestions were made in recent threads; I won't relist them here,
 but they have my full +1 support.  I hope those at ApacheCon hash
 something great out.

 *** We need to get back many of the disenfranchised Apache 1.3 developers

 Killing Apache 1.3 is not a good option.  There is a strong business
 need in many places to stay with Apache 1.3.

 The better option is reopening the 1.3 tree.
 Release 1.4 and open a 1.5 dev tree, with the specific intent on
 having the 1.4 release eventually map _directly_ into a _seamless_
 upgrade to Apache 2.x, with very easy and clear directions for using
 a reverse proxy for those legacy 1.3 third-pary modules.)  While
 upgrading is not hard for developers, Apache is not a simple product.
 We need an even-better (tm) way to get users from There (Apache 1.3)
 to Here (Apache 2.x).  Yes, more trees are extra work, but this
 community is rapidly deteriorating without them.

 *** We need to get more people using Apache 2.x

 Apache 2.x is not going to get any better than it is now until more
 people start using it in the real world (outside the lab).  Welcoming
 back the 1.3 developers and aiding the transition is one piece.
 Making this forum more responsive (e.g. with better patch management)
 is another.  Project leadership is the biggest key.

 If the Apache project leaders put their heads together, give some
 direction to development and patch management, and ask for help,
 I'm sure there will be a groundswell of supporters, me among them.

 Cheers,
 Glenn

Re: consider reopening 1.3

2003-11-16 Thread Jeff Trawick

Glenn wrote:

- lack of clear leadership and even basic direction
At present I see most of the time volunteered by developers to be spent 
communicating with users on the bug db and trying to fix bugs.  That sounds all 
well and good to me.

If somebody wants something big implemented that they cannot do themselves, let 
them compel (lead) the others to want to work on it.  If not, so be it.

  scratch-an-itch development is fine and good, but not in total chaos
What is this total chaos?  That everybody doesn't get in a room and map out 
what everybody is going to be doing?  This is volunteer work.  Some of us are 
spending quite a few personal funds this week flying somewhere to get in a room 
together and hash through some issues.

Sure, if everybody running their web site on Apache httpd would pay ASF a few 
dollars a month, things could change, and maybe some of us could spend our long 
working hours working just on Apache httpd.  But that isn't the situation.  And 
I am not interested in this turning into a big business.  And for many of us, 
our day jobs are good influences on our httpd endeavors anyway, even while they 
take away time that could theoretically be spent making httpd the way you want 
it to work.

- cathedral development
  it appears that more than a few serious discussions have not happened
  on-list and instead happen on IRC or elsewhere (board rooms?) without
  apprising the list of what transpired.  (Or have there been absolutely
  no recent design discussions?)
As someone who

1) follows development pretty closely
2) works for a company that has multiple skilled httpd developers and could 
conceivably host these board room discussions
3) hardly ever logs on to IRC, much less sees much discussed there when I 
happen to be logged on (ooh ooh new conspiracy theory)

I don't see this being a problem.  YMMV.

- patch management
  many patches posted to this list or the bug db languish in limbo.
  Very little happens until a core contributor decides to take over a patch
  (more often than not it is more than simply shepherding it)
  Little feedback; it often feels like nobody's home to answer the phone...
This is a big hole which will be addressed, even if I have to quit my job, 
abandon my family, find shelter from the wind and rain somewhere that has WiFi 
access, etc.  (No, not really.  But this isn't a simple situation that can be 
solved by proclamation.  We already have the will, we just need to have some 
procedures to help us focus that will.)

- insufficient (developer) documentation
  sure, there's the source, but it takes a lot longer to wrap ones head
  around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such.
  The barrier to entry is much higher; solid design documents would be
  infinitely helpful
Documentation is a lot of work and largely thankless.  If somebody wants better 
docs, they should be ready to post patches to what is there already.  Or if 
they actually pay somebody for an Apache-based server, submit doc issues as 
defects to your vendor.  Or pay somebody to do it.  Or wait silently for 
somebody to do it for them.

- many new contributors are frustrated and discouraged
Hopefully keeping focus on patches will be a big help.

But I can't gloss over the fact that this is how new contributers become 
developers and then able to lead themselves to solutions for problems that they 
wish to see resolved:

Post patches for bugs that are central enough to core operations that existing 
developers will be compelled (and skilled enough) to review and shepherd them 
in.  Keep doing it for a while.  You'll get commit access.  You'll be a 
developer and be able to fix other non-core issues pretty much as you choose.

Posting patches for something relatively obscure or not generally applicable is 
not the way to become part of the developer community.  Some of these patches 
may find shepherds, but the surer path is to attack problems that affect 
everybody and/or are in areas that more people have the skills to review.

- dwindling community
  The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds
  with the rest of the world that relies on the venerable Apache 1.3
- ...
1.3 works well enough for most everybody.  That explains the situation well 
enough for me.

So where do we go from here?

*** We need better patch management
certainly!!

*** We need to get back many of the disenfranchised Apache 1.3 developers
Who are these people?

The better option is reopening the 1.3 tree.
Release 1.4 and open a 1.5 dev tree, with the specific intent on
having the 1.4 release eventually map _directly_ into a _seamless_
upgrade to Apache 2.x, with very easy and clear directions for using
a reverse proxy for those legacy 1.3 third-pary modules.)  While
upgrading is not hard for developers, Apache is not a simple product.
We need an even-better (tm) way to get users from There (Apache 1.3)
to Here (Apache 2.x).  Yes, more trees are extra work,

Re: consider reopening 1.3

2003-11-16 Thread Jess Holle

I would not use this as an argument to re-open 1.3, but:

The LDAP authentication module has a number of issues which have been 
languishing.  I really cannot gripe as I haven't fixed any -- just found 
some, but for some of us this module has become critical.  Apache 2 has 
incorporated LDAP authentication, but it is not yet getting mainstream 
attention.

How does that related to 2.0 vs. 1.3, etc?  As I see it, we're still 
somewhat in limbo in that Apache has incorporated LDAP authentication 
but not enough of the community has taken an interest in the module to 
see it to full stability quickly.  I for one am thus left torn between a 
fairly well understood bug set on Apache 1.3 LDAP authentication modules 
and Apache 2's.

[This is certainly not intended as a slight to those putting in serious 
effort on Apache 2's LDAP authentication modules.]

--
Jess Holle

Re: consider reopening 1.3

Thanks for your response, Jeff.
You present some excellent points and defenses and present worthy opinions.
I agree that there are lots of thankless, non-sexy tasks that would
help, but the core developers need more manpower.  I am hoping to
create new avenues for participation.

My goal is to get Apache 1.3 reopened.

To that end, you responded:

 I don't expect any of the current Apache developers would be interested in 
 this.  But plenty of people join the development community over time (see 
 previous comments) and theoretically the opinions could change.

Well, I am interested.  And some others on this list are interested.
What must we do to have the opportunity to scratch this itch?
I suggested releasing 1.4 and opening 1.5 dev, along with better
patch management, to which you also agree a better job need be done.

I do not think that the _current_ Apache is and _will forever be_ the
right tool for a web server.  The size of the bug database and feature
requests should be sufficient evidence to support this point.  I also
believe that there needs to be an even easier migration path from 1.3
to 2.x, despite how good it is already.

So what will it take to convince the core developers to reopen 1.3?
I'm less interested in opinions and more interested in getting something
done.

Thanks!
Glenn

Re: consider reopening 1.3

On Sun, 16 Nov 2003, Jeff Trawick wrote:
  *** We need to get back many of the disenfranchised Apache 1.3 developers
 
 Who are these people?

/me raises a hand

People have suggested that we have fewer developers today because Apache 2 
is too complex.  That the crappy economy has reduced the time people have 
to work on it.  Or that Apache-1.3 is simply good enough for most people.

I don't think it is any of that.  Hackers love to hack, but hackers are 
also practical creatures.  They hack on things that they need and use.  
They need and use Apache1 but we have taken our ball away and gone off to 
play another game.

Just compare the list of contributors today to 4 years ago if you want a 
list.

 I don't expect any of the current Apache developers would be interested in 
 this.  But plenty of people join the development community over time (see 
 previous comments) and theoretically the opinions could change.

I think the key word there is current

I also work for a large company with plenty of talented developers and
thousands of production Apache-1.3 servers along with hundreds of custom
Apache-1.3 modules.  It will be years before I can even consider Apache2,
given the architecture and API differences between the two.  If something
could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap perhaps
one day Apache2 will be an option, but today it is simply too big a gap to
jump and I am pretty sure the bulk of the Apache community is in the same
boat.

-Rasmus

Re: consider reopening 1.3

2003-11-16 Thread Jeff Trawick

Rasmus Lerdorf wrote:

*** We need to get back many of the disenfranchised Apache 1.3 developers
Who are these people?


/me raises a hand

Just compare the list of contributors today to 4 years ago if you want a 
list.
diff knows no reasons.

Too bad all these supposedly-disenfranchised people aren't around to review 1.3 
fixes.  1.3 would be healthier if they were.

Re: consider reopening 1.3

2003-11-16 Thread Graham Leggett

Rasmus Lerdorf wrote:

I also work for a large company with plenty of talented developers and
thousands of production Apache-1.3 servers along with hundreds of custom
Apache-1.3 modules.  It will be years before I can even consider Apache2,
given the architecture and API differences between the two.  If something
could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap perhaps
one day Apache2 will be an option, but today it is simply too big a gap to
jump and I am pretty sure the bulk of the Apache community is in the same
boat.
I think the key thing is bugfixes compared to features and 
architecture changes.

I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it 
can work better, so be it. But to actively encourage people to add 
features or architecture changes to v1.3, that simply turns v1.3 into 
something else no longer compatible with v1.3, which we already have: 
v2.0.

Regards,
Graham
--

Re: consider reopening 1.3

On Sun, 16 Nov 2003, Jeff Trawick wrote:
 Too bad all these supposedly-disenfranchised people aren't around to review 1.3 
 fixes.  1.3 would be healthier if they were.

And it is the reason for why they are not around that is in question here.  
Why wouldn't there be plenty of hackers around for a piece of software
used to widely?  Blaming the hackers seems a bit shortsighted.  Have a
look at the environment we have given them to operate in and at some of
the responses over the years people have gotten when they suggested new
features for 1.3.

-Rasmus

Re: consider reopening 1.3

On Sun, 16 Nov 2003, Graham Leggett wrote:
 I think the key thing is bugfixes compared to features and 
 architecture changes.
 
 I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it 
 can work better, so be it. But to actively encourage people to add 
 features or architecture changes to v1.3, that simply turns v1.3 into 
 something else no longer compatible with v1.3, which we already have: 
 v2.0.

We have two completely different pieces of software.  The fact that they 
are both called Apache is just marketing.  By saying bug fixes only in 1.3 
you are effectively telling people who want to work on it to get lost.  
There are plenty of evolutionary things that could be done in it short of 
the revolutionary jump to Apache2.  We know the jump is too big for a big 
chunk of the market but nobody seems to want to address that.  

-Rasmus

Re: consider reopening 1.3

2003-11-16 Thread Jeff Trawick

Rasmus Lerdorf wrote:

On Sun, 16 Nov 2003, Jeff Trawick wrote:

Too bad all these supposedly-disenfranchised people aren't around to review 1.3 
fixes.  1.3 would be healthier if they were.


And it is the reason for why they are not around that is in question here.  
Why wouldn't there be plenty of hackers around for a piece of software
used to widely?  Blaming the hackers seems a bit shortsighted.  Have a
look at the environment we have given them to operate in and at some of
the responses over the years people have gotten when they suggested new
features for 1.3.
The point was not to blame anybody.  Instead, I don't believe there are so many 
people as you imply.  Many of the people who are no longer developing have 
moved on to other interests/work/etc. and have dropped out of httpd dev because 
of that.

If somebody is no longer working on [EMAIL PROTECTED] because they feel 
disenfranchised, it is fair to point out that their skills are still very 
useful even if they don't want to mess with 2.x.

Re: consider reopening 1.3

2003-11-16 Thread Matthieu Estrade

Hi,

I understand many people still are with 1.3 and don't want to change because
it's stable.
But Coding modules with 1.3 is definitively not easy and require many time
core patch.

Apache 2.0 was design to give many really good features like threaded mpm,
filters etc...
When you look others web server, you can see Apache 2.0 is a good response
to IIS 6, but is still unstable.
Did you see all performances the others web server give ? did you see all
new features provided by all new web server ?
Only Apache 2.0 is able to offer the same services. No mem_cache in apache
1.3, No filters, noway to change output data without patching the core.
When you compare actual fashion which is to offer webserver with a coding
api to make dynamic website etc, i think Apache 2.0 is the solution, and
more, maybe include directly into it mod_php and mod_perl.

Apache 1.3 is still used and really stable, yes, but needs are changing more
and more and i think it's time to do more and more effort on Apache 2.0 to
make it stable, powerfull, and easy to use. It's my humble option :)

Regards,
Matthieu


- Original Message - 
From: Graham Leggett [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 8:39 PM
Subject: Re: consider reopening 1.3


 Rasmus Lerdorf wrote:

  I also work for a large company with plenty of talented developers and
  thousands of production Apache-1.3 servers along with hundreds of custom
  Apache-1.3 modules.  It will be years before I can even consider
Apache2,
  given the architecture and API differences between the two.  If
something
  could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap
perhaps
  one day Apache2 will be an option, but today it is simply too big a gap
to
  jump and I am pretty sure the bulk of the Apache community is in the
same
  boat.

 I think the key thing is bugfixes compared to features and
 architecture changes.

 I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it
 can work better, so be it. But to actively encourage people to add
 features or architecture changes to v1.3, that simply turns v1.3 into
 something else no longer compatible with v1.3, which we already have:
 v2.0.

 Regards,
 Graham
 --

Re: consider reopening 1.3

On Sun, 16 Nov 2003, Jeff Trawick wrote:
 The point was not to blame anybody.  Instead, I don't believe there are so many 
 people as you imply.  Many of the people who are no longer developing have 
 moved on to other interests/work/etc. and have dropped out of httpd dev because 
 of that.
 
 If somebody is no longer working on [EMAIL PROTECTED] because they feel 
 disenfranchised, it is fair to point out that their skills are still very 
 useful even if they don't want to mess with 2.x.

But the message they have gotten is that they are useful as bug fixers and 
documenters only.  All the fun stuff is reserved for people working on 
Apache2.  If that is an incorrect impression then we need to shout this 
from the rooftops and put up a big sign inviting people to submit any 
outstanding cool patches for 1.3 along with ideas for things they would 
like to see added.  

Basically I see us back in the NCSA days right now.  The ASF has mostly 
abandoned Apache1 and we are in that transition phase where people are 
looking at each other waiting for someone to step up and continue 
development on the code that everyone is using.  That is how Apache was 
born to begin with.

-Rasmus

Re: consider reopening 1.3

On Sun, Nov 16, 2003 at 12:04:28PM -0800, Rasmus Lerdorf wrote:
 Basically I see us back in the NCSA days right now.  The ASF has mostly 
 abandoned Apache1 and we are in that transition phase where people are 
 looking at each other waiting for someone to step up and continue 
 development on the code that everyone is using.  That is how Apache was 
 born to begin with.

+1 Telling point.  Ignore history at your peril.  -Glenn

Re: consider reopening 1.3

On Nov 16, 2003, at 4:12 AM, Glenn wrote:

- lack of clear leadership and even basic direction
  scratch-an-itch development is fine and good, but not in total chaos
Umm... this *is* the ASF. It's *developer* driven. The direction
is defined by the developers.
- cathedral development
  it appears that more than a few serious discussions have not happened
  on-list and instead happen on IRC or elsewhere (board rooms?) without
  apprising the list of what transpired.  (Or have there been 
absolutely
  no recent design discussions?)
I agree that in some cases, irc is replacing dev@, which is
Not Good. Thank God we haven't started using stupid wikis.
- patch management
  many patches posted to this list or the bug db languish in limbo.
  Very little happens until a core contributor decides to take over a 
patch
  (more often than not it is more than simply shepherding it)
  Little feedback; it often feels like nobody's home to answer the 
phone...
- insufficient (developer) documentation
  sure, there's the source, but it takes a lot longer to wrap ones head
  around the Apache2 paradigms than it did for Apache 1.3 BUFFs and 
such.
  The barrier to entry is much higher; solid design documents would be
  infinitely helpful
- many new contributors are frustrated and discouraged
  see all of the above
  The voluble Kevin Kiley said it well:
  Make it EASY to contribute... not a nightmare.
The above are *not* 1.3 issues, per se, but httpd ones.

*** We need to get back many of the disenfranchised Apache 1.3 
developers

Killing Apache 1.3 is not a good option.  There is a strong business
need in many places to stay with Apache 1.3.
The better option is reopening the 1.3 tree.
Release 1.4 and open a 1.5 dev tree, with the specific intent on
having the 1.4 release eventually map _directly_ into a _seamless_
upgrade to Apache 2.x, with very easy and clear directions for using
a reverse proxy for those legacy 1.3 third-pary modules.)  While
upgrading is not hard for developers, Apache is not a simple product.
We need an even-better (tm) way to get users from There (Apache 1.3)
to Here (Apache 2.x).  Yes, more trees are extra work, but this
community is rapidly deteriorating without them.

As noted many times, 1.3 is actively maintained but not
actively developed. To be honest, I've not seen that
many people saying I *really* want to add this to 1.3!.
If they had, chances are good that I'd +1 (not that what
goes into 1.3 is my decision...).
I'm curious how a 1.4 or whatever would make it easier for
people to make that transition. What would 1.4 have or be
for that to happen?

Re: consider reopening 1.3

On Nov 16, 2003, at 2:23 PM, Glenn wrote:


I don't expect any of the current Apache developers would be 
interested in
this.  But plenty of people join the development community over time 
(see
previous comments) and theoretically the opinions could change.
Well, I am interested.  And some others on this list are interested.
What must we do to have the opportunity to scratch this itch?
I suggested releasing 1.4 and opening 1.5 dev, along with better
patch management, to which you also agree a better job need be done.
I do not think that the _current_ Apache is and _will forever be_ the
right tool for a web server.  The size of the bug database and feature
requests should be sufficient evidence to support this point.  I also
believe that there needs to be an even easier migration path from 1.3
to 2.x, despite how good it is already.
So what will it take to convince the core developers to reopen 1.3?
I'm less interested in opinions and more interested in getting 
something
done.

Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
reopening 1.3 implies that it becomes 1.4?
But as the RM for the last X 1.3 releases, I think (hope) that
it's obvious that I think the 1.3 tree still has a lot of
life and a lot of interest in it. The less-than-expected
migration from 1.x to 2.x has not happened, and the reasons
why are many and few. It's for that reason, and others,
that I try to keep 1.3 going.
I've never considered 1.3 closed so I see no need to re-open
it. Maybe open it up more, that is, by allowing new features to
be added, etc... I'm certainly ++1 about that. But I think
confusing things with a 1.4/1.5 branch doesn't make sense, unless
people can *actually* specify what would require a bump like that...
So:

   +1 for officially allowing active development on 1.3
   -1 for 1.4/1.5 just because

Re: consider reopening 1.3

2003-11-16 Thread Marc G. Fournier



On Sun, 16 Nov 2003, Jim Jagielski wrote:

 I'm curious how a 1.4 or whatever would make it easier for people to
 make that transition. What would 1.4 have or be for that to happen?

I was kind of wondering this one too ... I thought the biggest headache of
moving from 1 - 2 was that the APIs had changed?

Re: consider reopening 1.3

On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote:
 As noted many times, 1.3 is actively maintained but not
 actively developed. To be honest, I've not seen that
 many people saying I *really* want to add this to 1.3!.
 If they had, chances are good that I'd +1 (not that what
 goes into 1.3 is my decision...).

Oh, how about my (effectively) 2-line patch which adds vhost
to the error log, which I have posted to this list NO LESS THAN 6 TIMES
and spaced out over the past 6 MONTHS in three different formats, using
a global, expanding server_rec, and with #defines.

Pardon me for being PO'd and thinking that there is NO DEVELOPMENT
(besides critical security fixes) happening on 1.3.

 I'm curious how a 1.4 or whatever would make it easier for
 people to make that transition. What would 1.4 have or be
 for that to happen?

I have some different ideas.  One is to distribute APR with 1.3 so
that modules developers could incrementally move their modules to APR.

Personal experience: I am writing a module for 1.3 and 2.0 and the only
code reuse I manage to achieve is where I said 'screw both the Apache 1.3
and Apache 2.0 models' and decided that my module would only work on POSIX
compliant systems, and wrote my own POSIX compliant socket routines.  If I
had access to APR in 1.3, I could maintaining my module with 2.0 paradigms
and would be able to keep my module working with 1.3 with much less
additional effort.

Please note: I'm not in favor of implementing major changes to 1.3 that
are not in-line with Apache 2.x, but am in favor of continuing bug fixes
and making the eventual transition to 2.x easier.

Cheers,
Glenn

Re: consider reopening 1.3

On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote:
 Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
 reopening 1.3 implies that it becomes 1.4?

Only semantics.  .4 is even, so stable; .5 is development and less stable

+1 for officially allowing active development on 1.3
-1 for 1.4/1.5 just because

+1 for more active development on 1.x no matter what it's called.
We're on the same page.

Cheers,
Glenn

Re: consider reopening 1.3

On Nov 16, 2003, at 3:57 PM, Glenn wrote:
Oh, how about my (effectively) 2-line patch which adds vhost
to the error log, which I have posted to this list NO LESS THAN 6 TIMES
and spaced out over the past 6 MONTHS in three different formats, using
a global, expanding server_rec, and with #defines.
Ok, that's true, but that *really* does not translate to
a downpour of disenfranchised 1.3 developers begging for 1.3
to be re-opened :)
I'm curious how a 1.4 or whatever would make it easier for
people to make that transition. What would 1.4 have or be
for that to happen?
I have some different ideas.  One is to distribute APR with 1.3 so
that modules developers could incrementally move their modules to APR.

Personal experience: I am writing a module for 1.3 and 2.0 and the only
code reuse I manage to achieve is where I said 'screw both the Apache 
1.3
and Apache 2.0 models' and decided that my module would only work on 
POSIX
compliant systems, and wrote my own POSIX compliant socket routines.  
If I
had access to APR in 1.3, I could maintaining my module with 2.0 
paradigms
and would be able to keep my module working with 1.3 with much less
additional effort.

Please note: I'm not in favor of implementing major changes to 1.3 that
are not in-line with Apache 2.x, but am in favor of continuing bug 
fixes
and making the eventual transition to 2.x easier.

Interesting, but if the usage of APR was that deep within 1.3, then
wouldn't backwards compatibility with 1.3 go out the window.
I'm guessing this is your 1.4/1.5 branch. But that doesn't help
the 1.3 people at all, since (if I'm understanding you correctly)
all this does is create another Apache version...
I may be misunderstanding you... or do you mean just have
Apache 1.3 APR aware and not for 1.3 to *use* it per se,
but allow for modules to call APR... That would be useful,
but anything deeper than that would scare people I think...
APR is just as new as Apache 2.0.

RE: consider reopening 1.3

2003-11-16 Thread Paul Querna

 just to pop my 2 cents worth in here ... I have some clients that 
 have deployed under Apache2 ... the major headache(s) that I've had 
 to date is that the FreeBSD thread support is still listed as unusable:
 
 * If you are building on FreeBSD, be aware that threads will
   be disabled and the prefork MPM will be used by 
 default,  as threads do not work well with Apache on 
 FreeBSD.  If  you wish to try a threaded Apache on 
 FreeBSD anyway, use  ./configure --enable-threads.

On FreeBSD 4.X it is broken(and will be forever?).  On FreeBSD 5.X, use KSE
threading (which may become the default in the future 5.2 release anyways?)
and it works great. man libmap.conf on a FreeBSD box for information on todo
this.(see also: freebsd-threads mailing list)
 
 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

 everytime someone asks about Apache2 on the PHP mailing lists, the general
 answer seems to be we're waiting for the API to settle down ...

Well, I think that excuse is BS. Apache 2.0.X is keeping binary compatibility
now.  Not too many major API changes that I am aware of.

 For me, the big benefit to Apache2 is/will be going to threaded, so until
 either the FreeBSD/threaded issue is resolved, I'm stuck with 
 Apache1 :(

I use FreeBSD 5.1/current with the worker MPM with libkse. 
'works for me'

-Paul Querna

Re: consider reopening 1.3

Glenn wrote:
 
 On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote:
  Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
  reopening 1.3 implies that it becomes 1.4?
 
 Only semantics.  .4 is even, so stable; .5 is development and less stable
 

Personally, I've never liked that methodology Unless *really*
controlled, I think it almost restricts development, since the 1.5
tree kind of gets super developed and only occasionally are
safe things brought down to 1.4. Other development teams
do this much better than we do, IMO. With our development
scenario, and they way we are structured (no benevolent dictator),
having one tree, which is developed and polished, seems almost
healthier.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: consider reopening 1.3

On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote:
 On Nov 16, 2003, at 3:57 PM, Glenn wrote:
 
 Oh, how about my (effectively) 2-line patch which adds vhost
 to the error log, which I have posted to this list NO LESS THAN 6 TIMES
 and spaced out over the past 6 MONTHS in three different formats, using
 a global, expanding server_rec, and with #defines.
 
 
 Ok, that's true, but that *really* does not translate to
 a downpour of disenfranchised 1.3 developers begging for 1.3
 to be re-opened :)

Well, you asked for an example. :)
The patch is required in my environment.

[snip]

 Interesting, but if the usage of APR was that deep within 1.3, then
 wouldn't backwards compatibility with 1.3 go out the window.
 I'm guessing this is your 1.4/1.5 branch. But that doesn't help
 the 1.3 people at all, since (if I'm understanding you correctly)
 all this does is create another Apache version...
 
 I may be misunderstanding you... or do you mean just have
 Apache 1.3 APR aware and not for 1.3 to *use* it per se,
 but allow for modules to call APR... That would be useful,
 but anything deeper than that would scare people I think...
 APR is just as new as Apache 2.0.

The latter.  Only that it be available so that I can spend my
time developing with Apache2 paradigms and have most of them
translate to usefullness on Apache 1.3.  Sort of a like a
forward-compatibility to 2.0 in the same way that ap_compat.h
is a backward-compatibility from 2.0 to 1.3.

I think both Rasmus and I have voiced that there needs to be a
better migration path for third-party developers to port modules
to 2.x.  Migrating a stock Apache 1.3 to Apache 2.0 is trivial,
but this is not the case when legacy third-party modules are
involved.

Cheers,
Glenn

RE: consider reopening 1.3

2003-11-16 Thread Marc G. Fournier



On Sun, 16 Nov 2003, Paul Querna wrote:

  just to pop my 2 cents worth in here ... I have some clients that
  have deployed under Apache2 ... the major headache(s) that I've had
  to date is that the FreeBSD thread support is still listed as unusable:
 
  * If you are building on FreeBSD, be aware that threads will
be disabled and the prefork MPM will be used by
  default,  as threads do not work well with Apache on
  FreeBSD.  If  you wish to try a threaded Apache on
  FreeBSD anyway, use  ./configure --enable-threads.

 On FreeBSD 4.X it is broken(and will be forever?).  On FreeBSD 5.X, use KSE
 threading (which may become the default in the future 5.2 release anyways?)
 and it works great. man libmap.conf on a FreeBSD box for information on todo
 this.(see also: freebsd-threads mailing list)

'k, maybe expand the comment in the INSTALL file to address this?

  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 ...

Re: consider reopening 1.3

2003-11-16 Thread Greg Marr

On Sun, 16 Nov 2003 16:21:04 -0500
 Glenn [EMAIL PROTECTED] wrote:
On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote:
I may be misunderstanding you... or do you mean just have
Apache 1.3 APR aware and not for 1.3 to *use* it per se,
but allow for modules to call APR... That would be useful,
but anything deeper than that would scare people I think...
APR is just as new as Apache 2.0.
The latter.  Only that it be available so that I can spend my
time developing with Apache2 paradigms and have most of them
translate to usefullness on Apache 1.3.  Sort of a like a
forward-compatibility to 2.0 in the same way that ap_compat.h
is a backward-compatibility from 2.0 to 1.3.
I believe that there has been some discussion on this list in the past 
about people using APR with 1.3 modules.  There should be no 
requirement that httpd use APR for a module to use it.

Re: 1.3 Wishlist: (Was: Re: consider reopening 1.3)

On Sun, 16 Nov 2003, Jim Jagielski wrote:
 So a useful topic is: What is *missing* in 1.3 that needs to be 
 addressed.
 What are the features/additions that the disenfranchised 1.3 developers
 want to add to 1.3...

How about support for chunked compressed responses right in 
src/main/buff.c where it belongs (given we don't have filters in Apache1)

That alone would probably warrant a bump to 1.4.  I think people are 
thinking 1.4 because adding any significant features between 1.3.29 and 
1.3.30 would seem pretty odd.

-Rasmus

RE: consider reopening 1.3

2003-11-16 Thread Marc Slemko

What exactly do people want in a 1.4 and why is making that fit into 2.0
not an option?

So far I can recall seeing a few reasons why people aren't moving to 2.0.

1. they have no need to change, so they don't.  Why would having a
1.4 then 2.0 will make them have a need to make two changes?  If people
don't need to change, then thats great.  Most Apache installations are
more or less install and forget.  I'm not worried about these people,
they are happily using Apache, if they don't want to upgrade that is just
fine.

2. New module API making it hard to migrate.  This is certainly a problem
for a certain set of users.  I'm not sure how typical that set is.
Rasmus is not a typical user of Apache.  Since this set of users tends
to be more technically adept than others, however, it certainly may be
a big enough set that there is enough support from them to put in the hours
on a more evolutionary successor to 1.3.  However, I don't see how
a 1.4 would be a migration path to 2.0.  It would be a completely separate
path that would just be an approach to delay, possibly indefinitely,
migration to 2.0.  That isn't necessarily a bad thing in and of itself,
but it is different from having a 1.4 be some sort of migration path to
2.0.

3. Threading issues.  This is a red herring; threading issues can be a
reason why moving to 2.0 wouldn't give someone enough of a reason to make
it worthwhile, but they do not block anyone moving to 2.0.  if they
don't want to use threads, they don't have to use threads.

4. they wouldn't mind changing, but the upgrade hassles are too great.

5. stability, or perceived stability.

Apache is developer driven.  That results in it going where the more
technically capable user wants it to go, which includes companies funding
Apache development for their own reasons.

I'd like to encourage those people who are interested in contributing to
some version of Apache to consider if there is any way that instead of
starting with 1.3 and modifying it to have more features and more
bugfixes, some of which are already in 2.0 or are being worked on in 2.0
or people want for 2.0, they could work on making it easier to migrate
from 1.3 to 2.0.

I am not concerned that people are not upgrading to 2.0 unless they
want to upgrade to something but 2.0 will not work for them.

Re: consider reopening 1.3

2003-11-16 Thread Ben Collins-Sussman

On Sun, 2003-11-16 at 11:11, Jeff Trawick wrote:

  - patch management
many patches posted to this list or the bug db languish in limbo.
Very little happens until a core contributor decides to take over a patch
(more often than not it is more than simply shepherding it)
Little feedback; it often feels like nobody's home to answer the phone...
 
 This is a big hole which will be addressed, even if I have to quit my job, 
 abandon my family, find shelter from the wind and rain somewhere that has WiFi 
 access, etc.  (No, not really.  But this isn't a simple situation that can be 
 solved by proclamation.  We already have the will, we just need to have some 
 procedures to help us focus that will.)

FWIW:  in the Subversion project, we've assigned the hat of patch
manager to a volunteer in the community.  He watches patches come in. 
If any patch goes unanswered for a week or more, the patch manager files
it in the issuetracker.  No more lost patches.  If anything, it makes
the patches even more prominent -- when developers are scanning the bug
database for a quickie to fix, the small patches stand out.

Re: consider reopening 1.3

2003-11-16 Thread Kyle Hamilton

I agree with Matt that Apache2 needs to be rdy for IIS but we need to make a
choice here between 1.3-1.4 and 2
-Kyle Hamilton
www.kylehamilton.net
www.kylehamilton.com
559-593-1210
- Original Message -
From: Matthieu Estrade [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 12:02 PM
Subject: Re: consider reopening 1.3

 Hi,

 I understand many people still are with 1.3 and don't want to change
because
 it's stable.
 But Coding modules with 1.3 is definitively not easy and require many time
 core patch.

 Apache 2.0 was design to give many really good features like threaded mpm,
 filters etc...
 When you look others web server, you can see Apache 2.0 is a good response
 to IIS 6, but is still unstable.
 Did you see all performances the others web server give ? did you see all
 new features provided by all new web server ?
 Only Apache 2.0 is able to offer the same services. No mem_cache in apache
 1.3, No filters, noway to change output data without patching the core.
 When you compare actual fashion which is to offer webserver with a coding
 api to make dynamic website etc, i think Apache 2.0 is the solution, and
 more, maybe include directly into it mod_php and mod_perl.

 Apache 1.3 is still used and really stable, yes, but needs are changing
more
 and more and i think it's time to do more and more effort on Apache 2.0 to
 make it stable, powerfull, and easy to use. It's my humble option :)

 Regards,
 Matthieu

 - Original Message -
 From: Graham Leggett [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Sunday, November 16, 2003 8:39 PM
 Subject: Re: consider reopening 1.3

  Rasmus Lerdorf wrote:

   I also work for a large company with plenty of talented developers and
   thousands of production Apache-1.3 servers along with hundreds of
custom
   Apache-1.3 modules.  It will be years before I can even consider
 Apache2,
   given the architecture and API differences between the two.  If
 something
   could be done in an Apache-1.4 and 2.1/2.2 to help bridge the gap
 perhaps
   one day Apache2 will be an option, but today it is simply too big a
gap
 to
   jump and I am pretty sure the bulk of the Apache community is in the
 same
   boat.

  I think the key thing is bugfixes compared to features and
  architecture changes.

  I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it
  can work better, so be it. But to actively encourage people to add
  features or architecture changes to v1.3, that simply turns v1.3 into
  something else no longer compatible with v1.3, which we already have:
  v2.0.

  Regards,
  Graham
  --

Re: consider reopening 1.3

2003-11-16 Thread david

 Ok, so Apache2 uptake is slower than desired for some (not all) on this
 list.  That's only logical given the success and therefore inertia to stay
 with Apache 1.3.  But there are more than a few other factors mentioned in
 recent threads that are contributing to Apache2 development stagnation.
 Ignore for a moment that vendors have only recently begun shipping Apache2
 as the default web server instead of Apache 1.3.  Stas pointed out some
 serious problems.  I reformulate them slightly differently here.

Forgive my lack of english, but how can we reopen something that has never
been closed?

david

Re: consider reopening 1.3

2003-11-16 Thread Justin Erenkrantz

--On Sunday, November 16, 2003 4:04 PM -0500 Glenn 
[EMAIL PROTECTED] wrote:

On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote:
Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
reopening 1.3 implies that it becomes 1.4?
Only semantics.  .4 is even, so stable; .5 is development and less stable
Our versioning policy only applies to 2.x series, not 1.x.  -- justin

FreeBSD threads was RE: consider reopening 1.3

2003-11-16 Thread Justin Erenkrantz

--On Sunday, November 16, 2003 5:20 PM -0400 Marc G. Fournier 
[EMAIL PROTECTED] wrote:

On FreeBSD 4.X it is broken(and will be forever?).  On FreeBSD 5.X, use KSE
threading (which may become the default in the future 5.2 release anyways?)
and it works great. man libmap.conf on a FreeBSD box for information on todo
this.(see also: freebsd-threads mailing list)
'k, maybe expand the comment in the INSTALL file to address this?
Well, we've asked for confirmation of FreeBSD threading 'working' on the 
[EMAIL PROTECTED] - which as a platform-specific issue is the 'right' mailing 
list for this topic - not [EMAIL PROTECTED]

FWIW, the FreeBSD port maintainer has asked us to enable threads on all 
versions, but we've (so far) yet to receive a reply that indicates that the 
FreeBSD's threading works properly.  The only reply we received so far was 
that it isn't fixed with FreeBSD - even 5.1.  So, if you have something to 
add, please contribute on the right list.

Thanks!  -- justin

Re: consider reopening 1.3

2003-11-16 Thread Ian Holsman

Glenn wrote:

On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote:

Oh, how about my (effectively) 2-line patch which adds vhost
to the error log, which I have posted to this list NO LESS THAN 6 TIMES
and spaced out over the past 6 MONTHS in three different formats, using
a global, expanding server_rec, and with #defines.
this is not a 1.3 thing, this is a dev@ thing.
your patch could have been posted for 2.0 and got the same response.
(and I'm not saying you should not be pissed off, just that this is not 
a 1.3 thing)
I have some different ideas.  One is to distribute APR with 1.3 so
that modules developers could incrementally move their modules to APR.
why can't you just link APR into your 1.3 module? I don't think there 
would be any technical reason not to.

Please note: I'm not in favor of implementing major changes to 1.3 that
are not in-line with Apache 2.x, but am in favor of continuing bug fixes
and making the eventual transition to 2.x easier.
Cheers,
Glenn

Re: 1.3 Wishlist: (Was: Re: consider reopening 1.3)

2003-11-16 Thread Aaron Bannert

On Sun, Nov 16, 2003 at 03:54:59PM -0500, Jim Jagielski wrote:
 I'm also curious about what a 1.4/1.5 would do that the current 1.3
 does not which would provide a seamless upgrade. Are you talking
 API or what? As someone who's preformed numerous such migrations,
 the actual mechanics of doing so are meager, especially if
 you stay prefork.

sendfile?

-aaron

Re: consider reopening 1.3

On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote:
 Glenn wrote:
 I have some different ideas.  One is to distribute APR with 1.3 so
 that modules developers could incrementally move their modules to APR.
 
 why can't you just link APR into your 1.3 module? I don't think there 
 would be any technical reason not to.

Because then I would have to require that APR be installed, which is a
lot harder than just requiring say apache-1.3.30.

Right now, most people do something like rpm -Uvh apache-1.3.29rpm
and things work.  If APR were distributed with apache-1.3.30, then I
could say requires apache-1.3.30 and it would not be much of a stretch
to have them install it.


It should be possible for many modules to keep a single codebase for
both Apache 1.3 and Apache 2.x, with minimal #defines around areas
that manipulate BUFF vs filters and brigades.  Right now, it is not.

Cheers,
Glenn

RE: consider reopening 1.3

On Sun, 16 Nov 2003, Marc Slemko wrote:
 3. Threading issues.  This is a red herring; threading issues can be a
 reason why moving to 2.0 wouldn't give someone enough of a reason to make
 it worthwhile, but they do not block anyone moving to 2.0.  if they
 don't want to use threads, they don't have to use threads.

I have always had the feeling that Apache2+prefork was a bit of a 
second-class citizen.  I have tested it periodically over the past 2 years 
and it has never gotten anywhere close to Apache1 in performance.  I ran 
another test of 1.3.29 vs 2.0.48-prefork just now just to make sure I 
wasn't blowing pure smoke here and here is what I got:

Apache-1.3.29

Document Path:  /bench_main.php
Document Length:7832 bytes
 
Concurrency Level:  5
Time taken for tests:   2.038 seconds
Complete requests:  500
Failed requests:0
Broken pipe errors: 0
Total transferred:  4071500 bytes
HTML transferred:   3916000 bytes
Requests per second:245.34 [#/sec] (mean)
Time per request:   20.38 [ms] (mean)
Time per request:   4.08 [ms] (mean, across all concurrent requests)
Transfer rate:  1997.79 [Kbytes/sec] received
 
Apache-2.0.48

Concurrency Level:  5
Time taken for tests:   3.367 seconds
Complete requests:  500
Failed requests:0
Broken pipe errors: 0
Total transferred:  4028508 bytes
HTML transferred:   3931622 bytes
Requests per second:148.50 [#/sec] (mean)
Time per request:   33.67 [ms] (mean)
Time per request:   6.73 [ms] (mean, across all concurrent requests)
Transfer rate:  1196.47 [Kbytes/sec] received

I did try more requests, different concurrency levels and I tweaked the 
config of both to be as close as I could make them.

Looking at the total bytes tranferred, Apache2 is sending less mostly
because I forgot to remove the p3p module from my Apache1 setup which adds
a big long nasty p3p header to every response, but even with that Apache1
was way faster.

The benchmark itself is a standard little PHP thing I use to test stuff, 
so it may be that our Apache2Handler for PHP is crap and we aren't smart 
enough to write a decent Apache2 module.

-Rasmus

Re: consider reopening 1.3

2003-11-16 Thread Ian Holsman

Glenn wrote:

On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote:

Glenn wrote:

I have some different ideas.  One is to distribute APR with 1.3 so
that modules developers could incrementally move their modules to APR.
why can't you just link APR into your 1.3 module? I don't think there 
would be any technical reason not to.


Because then I would have to require that APR be installed, which is a
lot harder than just requiring say apache-1.3.30.
Right now, most people do something like rpm -Uvh apache-1.3.29rpm
and things work.  If APR were distributed with apache-1.3.30, then I
could say requires apache-1.3.30 and it would not be much of a stretch
to have them install it.

huh???
you can get APR rpm's now.
and you can build the APR independant of httpd (and have it sit in 
/usr/local )
and thanks to apr-config/apr-util-config it's pretty dang easy to build 
with them.

It should be possible for many modules to keep a single codebase for
both Apache 1.3 and Apache 2.x, with minimal #defines around areas
that manipulate BUFF vs filters and brigades.  Right now, it is not.
these minimal changes is where the bugs come in.
if people aren't willing to move from their apache 1.3.26, they aren't 
doing to upgrade to this.

FWIW..
I'm -0.5 in opening up the 1.3 tree, as I see it as dead, the same as I 
see redhat 7.x is.
I'm not saying that people don't run production systems on it,
or don't rely on it, but that they are in *maintenance mode*. I don't 
think anyone proposes to run new sites with redhat 7.x now do they?

having 2 seperate active code bases is just going to mean that 2.x is 
going to have less people working on it, as they are going to have to 
spend time fixing/maintaining all the new stuff being added/breaking in 1.3

does anyone have any stats on how long it took to migrate from 1.2.x to 
1.3.x?

from what I can see three reasons why people don't move
* things are running fine
* too hard to migrate the modules
* Freebsd threading
as for migrating the modules, you'll just have to bite the bullet one 
day, as you will when you migrate off platform X when it is EOL'd.

Cheers,
Glenn

Re: consider reopening 1.3

2003-11-16 Thread Ian Holsman

Rasmus Lerdorf wrote:

I have always had the feeling that Apache2+prefork was a bit of a 
second-class citizen.  I have tested it periodically over the past 2 years 
and it has never gotten anywhere close to Apache1 in performance.  I ran 
another test of 1.3.29 vs 2.0.48-prefork just now just to make sure I 
wasn't blowing pure smoke here and here is what I got:

Apache-1.3.29

Document Path:  /bench_main.php
The benchmark itself is a standard little PHP thing I use to test stuff, 
so it may be that our Apache2Handler for PHP is crap and we aren't smart 
enough to write a decent Apache2 module.
I don't think it is due to you guys not having smart people rasmus, more 
a question of priorities, your focused on 5.0 right now, and most people 
are doing that. as the general impression I've seen on the php lists is 
that no one is using 2, no one is interested in spending the time in 
getting it to run faster.

maybe a better test would be to re-write your benchmark program in 'c'
and to the 1.3/2.0 module interface directly so you can then do remove 
factors like this out of the equation.

rant
I've never seen what use req/sec is on benchmarks.
most people have thier testing machine sitting on the other end of a 
switched 100mbs/1G network and just bang away.
what I see more interesting is:
	- #reqs/sec @ 30% cpu utilization, where the testing machines
	  are on medium-low bandwidth rate limiting
	- possibly where the meltdown point is. ie.. how many concurrent
	  requests can this server takes before it gets unusable (say
	  1sec response time)
	- cost of a server farm using server X to serve my business.

I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave 
no more energy proving/disproving which is faster.. 2.0 works for me, 
and thats all I really care about, not who else is using it.
/rant
-Rasmus

RE: consider reopening 1.3

2003-11-16 Thread Peter J. Cranstone

 What would 1.4 have or be for that to happen?

You have 12 million users - shouldn't be hard to simply ask them what they
would like to see.

Give the customer what he wants and he will be back for more. HTTP ain't
finished yet, plenty of room for some serious improvement.

And I'd also be seriously thinking about 64-bit and getting Apache around
the 4GB memory limitation.

Regards,


Peter




-Original Message-
From: Jim Jagielski [mailto:[EMAIL PROTECTED] 
Sent: Sunday, November 16, 2003 1:37 PM
To: [EMAIL PROTECTED]
Subject: Re: consider reopening 1.3

On Nov 16, 2003, at 4:12 AM, Glenn wrote:


 - lack of clear leadership and even basic direction
   scratch-an-itch development is fine and good, but not in total chaos

Umm... this *is* the ASF. It's *developer* driven. The direction
is defined by the developers.

 - cathedral development
   it appears that more than a few serious discussions have not happened
   on-list and instead happen on IRC or elsewhere (board rooms?) without
   apprising the list of what transpired.  (Or have there been 
 absolutely
   no recent design discussions?)

I agree that in some cases, irc is replacing dev@, which is
Not Good. Thank God we haven't started using stupid wikis.

 - patch management
   many patches posted to this list or the bug db languish in limbo.
   Very little happens until a core contributor decides to take over a 
 patch
   (more often than not it is more than simply shepherding it)
   Little feedback; it often feels like nobody's home to answer the 
 phone...
 - insufficient (developer) documentation
   sure, there's the source, but it takes a lot longer to wrap ones head
   around the Apache2 paradigms than it did for Apache 1.3 BUFFs and 
 such.
   The barrier to entry is much higher; solid design documents would be
   infinitely helpful
 - many new contributors are frustrated and discouraged
   see all of the above
   The voluble Kevin Kiley said it well:
   Make it EASY to contribute... not a nightmare.

The above are *not* 1.3 issues, per se, but httpd ones.

 *** We need to get back many of the disenfranchised Apache 1.3 
 developers

 Killing Apache 1.3 is not a good option.  There is a strong business
 need in many places to stay with Apache 1.3.

 The better option is reopening the 1.3 tree.
 Release 1.4 and open a 1.5 dev tree, with the specific intent on
 having the 1.4 release eventually map _directly_ into a _seamless_
 upgrade to Apache 2.x, with very easy and clear directions for using
 a reverse proxy for those legacy 1.3 third-pary modules.)  While
 upgrading is not hard for developers, Apache is not a simple product.
 We need an even-better (tm) way to get users from There (Apache 1.3)
 to Here (Apache 2.x).  Yes, more trees are extra work, but this
 community is rapidly deteriorating without them.



As noted many times, 1.3 is actively maintained but not
actively developed. To be honest, I've not seen that
many people saying I *really* want to add this to 1.3!.
If they had, chances are good that I'd +1 (not that what
goes into 1.3 is my decision...).

I'm curious how a 1.4 or whatever would make it easier for
people to make that transition. What would 1.4 have or be
for that to happen?

Re: consider reopening 1.3

Peter J. Cranstone wrote:
 
  What would 1.4 have or be for that to happen?
 
 You have 12 million users - shouldn't be hard to simply ask them what they
 would like to see.
 

Postal fees will be hell...
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: consider reopening 1.3

2003-11-16 Thread Kyle Hamilton

hehe postal fees
why dont we do something like what openoffice does and have people registar
there copys just so we can figure out demographics and such kind of like
what netcraft does
-Kyle
- Original Message -
From: Jim Jagielski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 4:15 PM
Subject: Re: consider reopening 1.3


 Peter J. Cranstone wrote:
 
   What would 1.4 have or be for that to happen?
 
  You have 12 million users - shouldn't be hard to simply ask them what
they
  would like to see.
 

 Postal fees will be hell...
 --

===
Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
   A society that will trade a little liberty for a little order
  will lose both and deserve neither - T.Jefferson

Re: consider reopening 1.3