Slashdot Mirror
Sites Rejecting Apache 2?
An anonymous reader writes "Vnunet
reports on the low adoption of Apache 2 has caused its producers to advocate freezing development of the open-source Web server until makers of add-in software catch up. Almost six months after the launch of Apache 2, less than one percent of sites use it, due to a lack of suitable third-party modules." I'm not sure where they are getting the freezing Apache development part, more talk about forking for 2.1 right now on the httpd mailing list. The article does have it right though that until there is a reason to upgrade and the modules are in place that adoption is not going to happen. While the cores of both Perl and PHP are thread-safe, the third-party modules are not. This renders one the larger reasons to use Apache 2.0, the threaded http support, useless for applications using either of these application layers. It comes down to the question of whether the third-party module writers are better off supporting what is used or what is new.
My main question is, what would it matter if sites weren't using apache 2.0, isn't it enough that open source software is being used??
Ignore the "p2p is theft" trolls, they're just uninformed
I'll use aolserver (aolserver.sf.net).
It's a stable and tested technology.
For my project I stuck with apache 1.3.x
Here's what would convince me to change.
... its always nice to know that the big boys have taken the plunge.
.. given that I bothered reading up on some of the early discussions.
-- References. Have any high profile apache sites migrated? While my sites are small
-- PHP Support. As of 4.2.0, Apache2 support was experimental. The change log does not show anything which says its supported.
-- Mod_gzip support. This is a big one. Mod_Gzip makes my sites download a extremely fast when users over dialup lines log in. This is true specially for low bandwidth countries in Asia. Mod_gzip support has left me fairly confused
Even with all of this.. I'm not likely to change unless there is a perceptible difference in the load / performance stats on my system during the switch.
I know Apache does not have any "customers" to support, but why were they so eager to break compatibility for Apache 1.3 modules in Apache 2.0? I know backwards compatibility code isn't sexy, but couldn't they keep the old module API and thunk it to the new API? Then Apache 2.0 could ship with rock-solid mod_php and mod_perl. Let modules developers migrate slowly on their own schedule.
Here's an interesting perspective from Ole Eichorn, the CTO of Aperio Technologies:
One of the more significant recent discontinuities occurred with the release of Apache 2.0. Although it has been under-reported, Apache 2.0 is significantly discontinuous (non-backward-compatible) with Apache 1.3. Many webmasters have decided not to upgrade for now, rather than have to recode their custom modules. And many of the custom modules out there are 3rd party, so the resources to make the changes are not readily available.
It is not clear to me why the discontinuity was required. There was no technical reason not to maintain backward compatibility. I think your essay gets it right, the people who made these decisions were not involved in the original development, and were not sufficiently aware of the impact their decisions would have on their developer community. Multi-threading processes, which inspired most of the discontinuity, primarily benefits Windows sites - a small proportion of Apache installations - and most Windows sites use IIS and aren't going to change.
I bet in a few years we'll be able to track Apache's decline as the leading web server back to this point.
cpeterso
As a software author, you really need to worry about your own users outpacing you. For instance, if someone likes a feature in Apache 2, and every module they use, except yours, works with Apache 2, people quickly discover that they don't need your module all that much anyhow.
Wasn't that everyone's experience when switching from Windows? You can't get program XYZ for Unix, so you discover that you never really needed it that much anyhow...
As a programmer, it always pays to be everywhere you possibly can. But, when it's open source, programmers don't care what's best for the user, so don't expect it to happen.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
That or where it started to fork.If people are unwilling to go 2.x, they'll put the effort into adding new stuff into 1.x. Are we seeing Open Source at work?
Xix.
"Everything is adjustable, provided you have the right tools"
The number one problem with Apache 2 is its reliance on threads, and its assumptions about threading models.
This will certainly not win me friends in the "everything should use threads because it's easier to do linear programming than to build a session reentrant state machine" camp, but...
Threads are useful for SMP scalability, but they aren't very useful for much else (I/O interleaving is adequately handled by most network stacks, the I/O interfaces themselves, and the fact that almost all the bytes being mode are being moved from the server to the client: the protocol is very asymmetric, even if you aren't pushing multimedia files). In most cases, threads are a liability.
Under Windows, they introduce data marshalling issues that have to be accounted for in user code -- not just in the modules which implement interpreters for that user code.
Under UNIX, threads are generally a loss, unless there is specific scheduler support for thread group affinity, when threads are running on the same processor. and CPU negaffinity, when there are multiple processors, to ensure that there is maximal usage of computer resources.
If you do the first, then you have the possibility of starvation deadlock for other applications: basically, it's not possible to do it correctly in the scheduler, you have to do it by means of quantum allocation, outside the scheduler. This means a threading approach such as scheduler activations, async call gates, or a similar technique. If you do the second, then you pay a serious penalty in bus bandwidth any time locality spans multiple CPUs -- in other words, it's useless to use SMP, if you have, for example, a shopping cart session that needs to follow a client cookie around.
Overall, this means that you were much better off using session state objects to maintain session state, rather than using threads stacks to do the same job. This is actually pretty obvious for HTTP, in any case, where requests are handled independently as a single request/response pair, and connection persistance isn't generally overloaded to imply session information (you can't do that because of NAT on the clinet side, multiple client connections by a browser on the client side, and server load balancing on the server side, etc.).
Overall, this factors out into threads bringing additional pain for module writers, without any significant performance or other benefit, unless you go SMP, and have a really decent threads and scheduler implementation -- which means you are running a recent IRIX or Solaris, which is a really limited fraction of the total web server market.
Frankly, they would have been a lot better off putting the effort into the management of connection state and MTCP or a similar failover mechanism, and worried about NUMA-based scaling, rather than shared memory multiprocessor with particular threads implementation scaling. The cost for what you get out of the switch is just too high.
-- Terry
This is why its always (usually) a good thing. At the least, the option for it.
Would it be possible to create a patch/module for Apache 2 that allows old modules ot be used?
Question
http://www.ironfroggy.com/
As far as I can judge, there are two reasons why people wouldn't adopt Apache 2.0 . First of all, Apache 1.3 works Just Fine (WOW) for most sites, and it can therefore be considered wise not to upgrade to a later version which is based on a less-tested code base than what one is currently running.
The other thing is suggested by the author of the original post, and has to do with the fact that Apache 2.0 breaks compatibility with old modules. Downward compatibility is one of the Commandments in software development, and it's quite possible that this is a major reason for admins to be reluctant to switch to Apache 2.0.
Interestingly, both expecting people to upgrade to a product that almost certainly contains yet-to-be-discovered bugs, and breaking compatibility with previous releases are frequently observed in the practices of the Great Stan of Redmond. It may therefore not be surprising that those admins running Apache (rather than It Isn't Secure) would not go with it.
Please correct me if I got my facts wrong.
On static and dynamic content it's slow about 10-15% ! Apache2 consume more CPU time than 1.3 on static content about 10-20%. Prefork, worker show almost the same performace on single CPU machines. So, when apache2 show at least the same perfomance I'l setup it on my server.
The "fuss" is they are still labeled as "experimental."
There are two very different angles to look at this problem from. Those who hack on linux in their spare time, and those who run mission-critical systems for their living.
Here in my basement, I run Debian Sid. I play with 2.5 series kernels. CVS doesn't phase me. And all is well, for if something gets screwed up, the only loss is my time, and there is more to be gained from the experience than there was lost to it. However, when the sun rises, and I make my way to work, the story is much different.
In the server room at work, I am responsible for the servers that host our client's websites, email, and DNS records. If something hits a bug, that something malfunctions. Maybe it hiccups, maybe it takes the entire box to it's knees. Given my druthers, I'd take the former, after all, if it just hiccups, it doesn't interfere with everything else. Now, I may think that I have a very firm grasp on what is happening on those boxes. I even pretend to think that I have a firm grasp on what is happening on my system here at home. My boss even trusts and respects my judgement. If I decided, for example, to replace our very stable and definately efficient-enough Apache 1.3.26, PHP, mod_gzip, etc. with the Apache 2.x and the corresponding modules, he wouldn't blink an eye. Why? Because he trusts me to make good decisions. I can't think of any better reason to stick with what is known to be stable, verses something that is "cooler," newer, or jus' phatter.
After all, as much as we like to think it, they don't pay us systems administrators to sit there and hack. They pay us to deliver systems that work.
kmem russian roulette: Aquillar> dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM
You're not forking a 15MB process for every concurrent connection. You're creating a PID for every concurrent connection; process memory with regards to fork under most UNIX systems is _copy_on_write_, which means it isnt getting copied until such a time as it is actually written to. There's no real gain in memory.
Multi-threading is NOT more efficient that multi-process. That is a blanket statement and my reply is as well. Linus did something smart in that he considered a process and thread one and the same. However, the upside is that whena Linux "thread" dies it does not kill off the "process". MS does this too when it uses Apartments, etc. In fact COM+ is an exact mirror of the Linux process, thread strategy.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
I don't understand why it matters. Apache 1.x is being used by people who are happy with it. Good. They're happy, ASF must be happy they're happy. Apache 2.x is being used by people who are happy to upgrade to it. They're happy, ASF must be happy they're happy. So, where's the problem? Does it matter to ASF that people aren't flocking to use Apache 2? People will migrate as and when they see a need to. This is a good thing, not a bad one. This is why free software is free. No-one is forcing anyone to do anything, but there is more choice. So, who isn't happy? Third party modules will be patched/re-written when there is sufficient need, not just for the sake of it. This is a good thing.
> Which means that php would have to be running as a external executable, which means performance drops.
"Drops" doesn't matter, the important question is, "drops by how much?" For sufficiently small values of 'drop', the security increase would be well worth the tradeoff.