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.

Comments

Apache 2.0 Threads

[TurboRoot]

The main benefit of Apache in the first place is the stability benefited from the fork() nature of it.

Apache 2.0 brings some nice and intresting new features that only a multithreaded server can bring, but these are all features already available in tons of other web servers..

Unfortuantly, the programmers working on Apache 2.0 don't know how to write thread safe code. Don't believe me? Go get the source yourself, cuddle up to a posix threading book and pull out a 100% correct threading library. (Like the FreeBSD one.) :)

Example... DONT USE SLEEP(3) in a multithreaded application!.. but whatever :)

What I am basically saying is.. I would't get apache 2.0 for production _yet_. Someday Apache 2.0 will be the model for how a stable multithreaded multi-protocol server can be written.

By the way, I normally don't take time out to actually post. But since my moderation and meta moderation privs were removed since i moderated a post I found intresting.. to be intresting. (The great slashdot troll investigation). About 500 people lost their moderation ability at that time. What a nice brave new world.

The advance is. I can now say what I truely feel and not care about karma.. because this place is a joke. :)

Re:Apache 2.0 Threads

[Anonymous Coward]

POSIX.1 specifies sleep(3) be both thread-safe and cancellation-safe.

Re:Apache 2.0 Threads

[ink]

Go get the source yourself, cuddle up to a posix threading book and pull out a 100% correct threading library. (Like the FreeBSD one.)

When did FreeBSD get 100% compliance?

http://www.idiom.com/~bko/bsd/freebsd-threads.txt

In addition, ngpth has been accepted by Linus and they are very close to 100% compliant as well as providing for M:N mapping to scale on multiple processors, and to give programmers choice of kernel or userland threads with standard calls. BSD is great and all, but you guys do way too much chest-pounding.

Re:Apache 2.0 Threads

[Electrum]

Well, generally, when I see something like sleep(3), it means that a thread is waiting for an event to finish.

That notation tells which manual section the name is in, not what parameters if any the function may be called with (many times the name is not a function). In this case, the "sleep" function is in manual section 3. i.e. you run "man 3 sleep".

Re:Apache 2.0 Threads

[Fweeky]

> a 100% correct threading library. (Like the FreeBSD one.)

FreeBSD's threading it actually supposed to be rather smelly - just ask on freebsd-hackers or so.

This is why Apache 2 on FreeBSD is best off sticking with the prefork MPM. The introduction of KSE's in -current will alleviate this, but that's still heavily in development.

Re:Apache 2.0 Threads

[Fweeky]

Should probably have included a link to http://people.freebsd.org/~jasone/kse/ for those who cba Googling; there is some good stuff about the current threading implimentations there too.

Re:Apache 2.0 Threads

[BusterB]

> POSIX.1 specifies sleep(3) be both thread-safe and cancellation-safe.

I don't think he's talking about sleep being thread-safe. I think he's talking about using sleep rather than a condition variable and a while loop to wait for access to a shared resource. The problem with using sleep is that it's entirely dependent on system load/ speed/ alignment of the moon. Code like that assumes that if it waits a certain amount of time, the resource will be free.

Imagine checking to see if a pool is dry, noticing that it is, coming back later and jumping in without looking. It might be full later, but it's much better to keep looking and not jump until the pool actually has water.

This type of thing is especially hard to debug when you upgrade your hardware and your software mysteriously fails. Suddenly, you're not sleeping long enough to get an exclusive lock on a shared resource.

Re:And...?

[TeknoHog]

Apache is doing a thing or two besides just calling "Passenger index.html, please contact gate 80". There are other, faster httpds around that focus on this simple task, for example Boa. (the joke works much better in Finnish)

Excellent Work - Worth the wait

[Dysan2k]

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

It's not just for break^H^H^H, er, files anymore

[Eryq]

Many sites use Apache as an application server or to serve dynamic-content; e.g., by using mod_perl (to deliver blazingly-fast dynamic content generated by Perl scripts), or as a flexible and solid front-end to Java servlet engines like JServ and Tomcat.

And far from being bloatware, Apache has (at least during 1.*) gotten more modularized over time, making it easier to fine-tune logging, access control, URL rewriting, etc, etc. I don't know squat about 2.x, but I expect good things.

Just the $0.02 of a Perl/Java hacker who uses it extensively...

Apache 2 is going to kick ass

[blackmateria]

I've been using Apache 2 on Linux and FreeBSD for about 2 months now (got into it while playing around with Subversion, another project that seems to be making excellent progress), and IMHO it is really going to rock the server world. Some major plusses:

• ./configure; make; make install (almost). No more APACI, thankfully.
• APR. It's already starting to be used by other projects.
• Totally rewritten mod_cache, mod_proxy, etc. Works much better now!
• Will actually work on Windows (well, some may not see this as a benefit, but whatever).

People have been complaining that Apache 2 is slow to come out, but from what I've seen lurking on the mailing list, it's because they want to ensure the quality of this release. They've also been talking about how they want a lot of beta testers, because (<rumor mode on>)they want to release soon, maybe even from 2.0.32. So get out there and beta test it!

---
Have you crashed Windows XP with a simple printf recently? Try it!

Re:Apache 2 is going to kick ass

[Electrum]

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.

There is more to that

[artur]

This is usually the case when you are serving static pages for a page that is viewed one time a day.

However, it gets complicated when you serve pages that are dynamically generated for various users. You want to be able to pass content of a file through various modules. You can tell that you want the page to go through mod_perl and then through SSL modules. You can also stack any modules in between.
The new version makes it easy.

Of course there is a lot of other things besides the "reading and shooting" files (IPv6, web caching, etc).

Performance results

[augustz]

I've been following performance results for 2.0, and wanted to let folks know that it doesn't seem clear to me that there is this huge performance gain waiting to happen.

http://webperf.org/a2/v29/Apache2_26-Nov-2001.html has some 2.x v. 1.x results.

Love to hear the lowdown on performance advantages of the new Apache from someone in the know or someone who has done some actual testing.

Also, PHP/Apache perl/Apache integration are probably very high on many folks lists, what is the status of those two vis a vis apache?

Re:Performance results

[BigBir3d]

Configurability is also very important. If 2.0 can be configured better than 1.x ever could, for me, than it will be faster, giving me more performance.

Re:Performance results

[Anonymous Coward]

the apache has several performance advantages.

1 lower memory footprint.
you can run a a server which normally took 4G of memory in 512M

2. speed
http://webperf.org/a2/v31/2002-02-11-v29/
http://webperf.org/a2/v31/2002-02-12-v31/
the page is similiar to the 'NEWS-STORY-NORMAL' column in the old one..

check out the response time in the graphs.. can v1.3 get a 1-1.5 second response time as CPU increases like that ?? doubt it
3. mtmalloc
we found that using mtmalloc with apache 2.0 gave us a performance increase of 30% (yes 30%) by preloading the library

4. v31 has got a different pool allocater, which reduces the mutex contention considerably.

nice to see someone is referenceing my benchmarks ;-)

BTW .. solaris 8/8 cpu/GCC v2.95

while your surfing webperf.org.. why not download the agent and run it for a while?

MSI Installer == Spiffy

[justin_w_hall]

First off, I have to rant about how much I love their precompiled MSI builds. Convincing my boss that installing a webserver to replace IIS would be easy was about 3 million times earlier with that... run it, click thru the wizard, once-over the config file and you're up. Now you, too, can escape the IIS headaches in less than five minutes!

With that said, has anyone tried the MSI for this latest beta? It didn't create the service for me automatically, and I wasn't sure if it was just my crackpipe or if it was an actual problem. Bug report's been filed already, just wanted to see if anyone else had any input...

Re:MSI Installer == Spiffy

[darkwhite]

Yeah, it's strange, because the previous beta does install the service. It's easy though, just run apache -i.

I've just switched to 2.0 a few days ago on win32... so far it's been about the same as 1.3 for me, the only thing I had a problem with is that it doesn't substitute paths for shebang lines in cgi-bin files, so I have to write out full paths (1.3 did). And the conf file from 1.3 doesn't exactly work right away with 2 (which would be nice), I had to tweak it. Otherwise it's great.

MySQL? PostgreSQL is better!

[Bistronaut]

-flame- -flame- -flame- OK, I was just kidding. I love PostgreSQL, but even I realize that when you don't need stability, speed, good SQL compliance or ... what was I saying again? -flame- -flame- -flame- Alright, back on topic, I'm pretty sure that you've been able to compile PHP4 for Apache 2.0 for quite a while now (at least the option has been there - maybe it's been broken?).

Re:MySQL? PostgreSQL is better!

[Fweeky]

The API's are not yet fixed, so they tend to break. You can probably compile CVS of PHP to the current beta Apache 2, but the next time they change something PHP will most likely track the CVS change, leaving the beta out in the cold again.

I managed to get mod_php + Apache 2b28 coexisting, but it liked to segfault a lot (even when idle) and always ended up eating 100% CPU. I even managed to add Zend 2 (next-gen PHP engine) to the mix, but, well, I haven't seen Apache fall over so much since I got PHP 4.0.0 to generate 50,000 internal errors on a single script.

perchild MPM

[slamb]

I'm a little disappointed by Apache 2.0 so far.

I've been looking forward to the perchild MPM. It can run different server processes under different UID/GIDs. This is important because mod_{perl,php,python,snake} run in-process with the Apache server. It's the only way to run them securely for different people other than a completely seperate webserver for each person (with its own IP address, configuration file, memory footprint, etc.)

But perchild doesn't really work:

• It's not portable to non-Linux platforms. (There was talk on the mailing list of marking it experimental because of this.)
• It hasn't compiled (even on Linux) out of the box in several releases. In 2.0.29, easy to fix but still doesn't work right. (Not compiling is a sure sign it hasn't been maintained.) Not quite as easy on 2.0.32. There's a patch, but it doesn't look right to me.
• It's easy to misconfigure it into running virtual hosts as root. (Bug report)

So, Apache 2.0 may be promising in the future...but when a feature I've been looking forward to for a long time is broken, I'm kind of disappointed.

Re:Much like Linux 1.0

[MeNeXT]

Why are you waiting for their OK? If this was MS it would be at version 3 already. The beta of open source is more reliable than most MS versions. The true final of an MS version is after SP2.

Re:Threads and processes : why?

[webperf]

I suggest you look at http://www.kegel.com/c10k.html for a great description on all the different types of architectures there are for webservers