httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <>
Subject RE: consider reopening 1.3
Date Mon, 17 Nov 2003 14:17:36 GMT

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

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

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	Done		12 million happy customers
1.4	64-bit	12 million potential customers

2.x	Work in progress	not sure how many customers?

I know where I would go.



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

Peter J. Cranstone wrote:

> In today's environment it's all about 2 words - price/performance. Show me
> that Apache 2.x can outperform 1.x by a factor 10 on the same box. 

Dig around... I posted a benchmark to this list early in 2.0 development
showing a 10x improvement of threaded 
2.0 over 1.3 on AIX. The test was rather unfair to 1.3 as I had the machine
swapping like crazy.  So my 
question to you is price/performance doing what? It would not be too
difficult to show a large performance 
improvement with 2.0 configured as a DMZ tier caching load balancing server
frontending a farm of backend 
application servers. 'Smart' load balancing (pick your algorithm) and active
fail-over support is not built in 
but would not be too difficult to add (I even posted a proof of concept to
the proxy dev list a couple of 
months back).  Tux is about the ultimate solution for serving static pages,
but I doubt it has much traction 
either. One other thing worth noting... most Apache installations run on
Linux. One of the big features of 
Apache 2, the threaded MPM, is completely worthless on Linux. The threaded
MPM runs pretty well on the new 
thread library but the new thread library will not become mainstream until
the 2.6 kernel (yea. I know some 
distros have it in 2.4, but that is somewhat controversial). Once the thread
library on Linux is stable, we 
may begin to see more thread safe packages available for things like


View raw message