Slashdot Mirror
Apache Server Nears 2.0
An Anonymous Coward writes: "The Apache httpd project has released a new beta of their apache 2.0 server (v32)". For those who have not been following the 2.0 development, this is the third beta that has been produced. The new version of Apache sports the new APR API and a new method for filtered I/O, and has been rewritten to make use of a hybrid thread/process model. With Covalent already selling a commercial version of 2.0, hopefully we will see a full release of the open source version in the near future.
Personally, I don't mind waiting on the Apache project to take their time and do it right. I believe 2.0 isn't bloatware, but a far more modular and extensible version of the worlds fav. web server. Personally I've been waiting for a WHILE to start using it. I'm not sure if PHP4 will compile against it yet. Maybe out of CVS it will.
With the new threading, it should manage to push out pages a lot faster under load, and make better use of the processors. Might have to go download today. Here's a project for those of you bleeding edgers out there. I've yet to manage this one myself:
Apache 2.0 + mod_perl + php4 (with support for MySQL 4.x) + mod_ssl.
I don't think non-CVS PHP4 will handle MySQL 4.x, but perhaps there are others that know how.
Back to topic, way to go guys!!
-What have you contributed lately?
The answer to that question is, dynamic transactions often access existing databases, which often have screwed up data models and require insert/updates in multiple tables. Some will run and scream "horror, horror, horror," but now that the .bomb blew up, more and more web developers are finding they have to work with bad, inefficient, poorly documented data models. Having multi-threading in Apache will improve it's scalability.
being able to plug in your domain SAM, with acls on the site. Also domain authentication with "web folders" (DAV) is another. Note: I will be happy to be corrected with a HOWTO that tells you how to point DAV at your PDC or SAMBA box here ... (without running a separate accounts database)
If serving huge amounts (>1 GB/hour)of static content from a single-CPU computer is what your server does, Apache is not for you.
A well designed non blocking server can run in multiple processes, to take advantage of multiple CPU's. Zeus does this.
But if you would stop to think for a while, you would see that no one does that. Nowdays, it's all about dynamic content. And in that case the overhead of using multiple threads is tiny compared to the added benefits of scalability and stability.
That's wrong. As I said, most of your requests will be static content. Take Slashdot, for example. This comment posting page is one perl page, and six images. Do you really need six extra processes for those images? Especially large Apache processes that have mod_perl and who knows what else compiled into them. Sure, the code pages should be shared, but it's still poor design.
It is actually possible to use a kernel-based server like Tux for static content and let Apache take care of the dynamic bits.
Sure you can do that, but wouldn't it be better to use a well designed server in first place, and not have to kludge around design flaws in the web server? Your web server should not be your application server. Your web server should be serving web pages. Your application server should be running applications. The Apache model of "build everything conceivable into the web server process" is a bad idea, and is not consistent with the unix philosophy of doing one thing, and doing it well.
Everyone knows CGI's are bad for performance because it causes forking a separate CGI process for each request. Turning the CGI's into Apache modules solves this problem, but not in an optimal way. Applications do not belong in the web server. A model such as FastCGI is a much better approach. It is similar to CGI, especially in the sense that it is easy to program for. But instead of running the process and using stdin/stdout as with a CGI, it connects to the FastCGI via a socket. Thus the application stays running, and there is no process creation overhead. It keeps any necessary load balancing on the application end where it belongs, and out of the web server.
Additionally, the application doesn't even need to be on the same box. You can have one or several application servers, and a single web server. A web server only needs to handle data. A single box should be able to fill your outbound pipe, or at least around 100mbits of it. If an application is slowing it down, then you need another application server, not another web server. It is unfortunate that the two are not seen as the separate entities that they should be.