Slashdot Mirror

Done and done... $50k and equivalent performance of the high end BIGIP stuff
http://www.zeus.com/news/press_articles/zeus-price-performance-press-release.html

Or use the Zeus Web Server - way faster then Apache, especially when running PHP using FastCGI.

Greg, I am intrigued to know your reaction to Zeus.com's claims (http://www.zeus.com/products/zws/features) that there are more websites running Zeus Web Server than Apache. Not sure where they got their numbers, but Netcraft (http://news.netcraft.com/archives/web_server_surv ey.html) definitely does not agree...

Their server is supposed to have been built from the ground up for pure speed and runs on most *nix os's. http://www.zeus.com/products/zws/index.html

Our web site serves about 3 millions pages a day on two gigabit links. The balancing rules are quite complex since the content is splitted on multiple servers and SANs. We use software load balancers: Zeus ZXTM on Gentoo Linux. The nice thing about software load balancers is that you can easily replace the hardware if it fails. Having a spare PC is way cheaper than a spare load balancer. We are very pleased with ZXTM so far. Very reliable, fast, and very flexible. It uses a PHP-like scripting language to process requests and you can really handle any specific backend architecture with that.

I actually thought that this was common knowledge--that Windows Server 2003 with ASPX was faster than Linux/Apache with PHP, or that Server 2003 was generally faster with static content. (I admit, I only glanced over the article, and Adobe Acrobat's search tool is the worst of crap, so sue me if it didn't mention ASPX).

1)ASP (not ASPX) are fairly flaky and recent versions are roughly comparable to, but slower than, PHP4 (not sure about 5), in general.

2) Windows is not very good at creating new processes quickly. This is why CGI (not fastCGI) in the platform is so glacially slow.
Let's have an example. Let's say that you make a dynamic webpage in which all content is generated by a C++ CGI program. Ignoring database access for the time being, since that dilutes the example, on Windows, the website would be MUCH slower than the same website written in ASPX, even though the actual execution time of the C++ program is shorter (assuming a competent C++ coder).
This is because for each request, Windows must create a new process (the CGI program), and destroy the process when the request is complete.
While the execution time is low, the process management overhead dwarfs the actual page runtime, because Windows doesn't do that sort of thing quickly. This is why CGI has long been blacklistedon Windows systems by good web devs, and this is one reason that Apache 1.x was such a dog on Windows. Apache 1.x creates a new Apache process for each request.

Now Linux, on the other hand, creates processes about as fast as it creates threads, which is to say, really damn fast. Apache 1 has always worked just fine on Linux (and indeed most Unix systems) because the overhead of creating a process, while significant, isn't slower than a dead slug stuck in frozen molasses like it is on Windows.
Apache 2.x allows requests to be served by a thread or a process, or a number of processes that each create several threads (any Apache gurus please correct me if any of this is off).
It follows that this isn't a big deal on Linux (because process creation isn't really much slower than thread creation), but is a very big deal on Windows.

Windows has ASPX, which is Microsoft's marketing term for the use of the .NET framework for web content delivery (get it--the 'X' makes it sound cool. Or something). .NET is compiled, and ASPX needs neither process nor thread creation. Like any .NET application, ASPX can run sort of close to native speeds (native + lots of wrapper overhead + generic memory management overhead and such.)

Yet Apache is still back here creating a process or thread for each and every request (note that there are some ways to speed things up. FastCGI comes to mind, but I don't want to get into the gory details that I don't know enough about). This is not the brightest way to do it in terms of performance, but then, Apache appears to have been designed for universality and configurability over raw throughput.

It is unwise to hold the attitude that Apache can't be beaten by IIS, especially when IIS is optimized for one platform--by the vendor of that platform. Apache isn't even the fastest on Linux. Take a look at Zeus webserver. It serves circles around Apache on any platform it supports--including Penguin land.
In fact, Zeus uses a technique called SendFile() which, oddly enough, is strikingly similar Microsoft's own TransmitFile() API. Hmm.

Think of it this way: Apache is to IIS as GCC is to ICC, at least in terms of performance and generality.
Intel's compiler (ICC) consistantly blows away GCC in terms of the performance and size of the compiled code, but GCC runs on just about anything with a CPU, can cross-compile, is free, doesn't pull any PHB evil tricks, and actually compiles things like the Linux kernel without pat

We run iPlanet on several hundred web servers and have a SunONE pilot looking to cover around 25 million users.

I have no idea what you are doing, so I don't know if this would help, but if I needed dozens or hundreds of web servers I would use Zeus Web Server. It's the best web server on the market and designed for high traffic, clustering and easy administration.

I use Zeus and because of it I don't need dozens of web servers.

Indeed competing with, say Apache or squid would be a hard sell.

Oh, really?

I remember reading within the PHP docs about how unsafe it was to use the 2.x release branch of Apache with PHP...something to do with thread safety if I recall.

PHP is not thread safe and likely never will be. The core is thread safe, but not all the extensions are guaranteed to be thread safe due to the external libraries they use. Thread safe issues likely won't show up during testing, but will show up in production under heavy load. This is the reason Zeus recommends using FastCGI instead of ISAPI for PHP, and the reason the recently released Zend WinEnabler uses FastCGI.

I strongly recommend using the FastCGI interface to PHP, even under Apache. The FastCGI interface is much faster than mod_php4 under Zeus and will likely faster under Apache too. It has the advantages that you can control resource usage better (no bloated PHP environment in every Apache process), run PHP as a different user than the web server and even run PHP on a different machine than the web server.

FastCGI rocks. It is a shame that many things are written as Apache modules and not FastCGI. The trend of "compiling everything into the web server" is bad engineering.

For something claiming to be "the fastest Web server ever". It certainly doesn't seem to be standing up to a slashdotting very well.

kind of a neat idea, actually.

Sounds like they need Zeus web server. Runs all of eBay's traffic just fine, better than Apache ever could.

What a dickhead. Okay, you go and stick your single Apache server and then have CNN broadcast the website URL. What?!? Your server can't handle that traffic load either?? Better check your assumptions, pal. Apache isn't the greatest either. Why not go out and get yourself a Zeus web server instead?

Sitting on security vulnerabilities until several fixes are available and releasing them as one advisory is a good trick to try to reduce the overal number of advisories, without actually having to improve the quality or security of the product.

For a while patches were announced on Thursdays and for a while before that it was Fridays. Fridays must have run too much overtime and shown up on the boardroom radar. Thursday in Seattle is already Friday in Europe so maybe this is a play to get MSTD-induced overtime back off the radar of European managers. With a legal cap of around 37.5 hours per week per tech, business can't afford too many IIS servers.

It is strange that any would try to. Microsoft-IIS is not a viable alternative to Zeus or Apache.

Hi
According to my tests BOA beats Apache.
BUT the ZEUS web server (www.zeus.com) which is 'feature complete' (including mod_perl in version 4.2) still beats both of them.
Have a nice day!

Yep. fnord is probably the fastest small web server available. There are basically two ways to engineer a fast web server: make it as small as possible to incur the least overhead or make it complicated and use every possible trick to make it fast.

If you need features that a small web server like fnord can't provide and speed is a must, then Zeus is probably the best choice. Zeus beats the pants off every other UNIX web server. It's "tricks" include non blocking I/O, linear scalability with regard to number of CPU's, platform specific system calls and mechanisms (acceptx(), poll(), sendpath, /dev/poll, etc.), sendfile() and sendfile() cache, memory and mmap() file cache, DNS cache, stat() cache, multiple accept() per I/O event notification, tuning the socket buffers, disabling nagle, tuning the listen queue, SSL disk cache, log file cache, etc.

Which design is better? Depends on your needs. It is quite interesting that the only way to beat a really small web server is to make one really big that includes everything but the kitchen sink.

I don't understand.

Their article is about building a high performance web server, and they tell people to use Apache.

Apache is featureful, but it has never been designed to be fast.

Zeus is designed for high performance.

The article supposes that money is not a problem. So go for Zeus. The Apache recommendation is totally out of context.

We gave up on throttling. It just doesn't work. And not from a technical standpoint, either. If you are going to do throttling, then you need a web server that does real throttling. The only one I know of is Zeus. It does real throttling, letting you limit the total bandwidth for all of a user's sites to a bytes/sec value. No Apache modules do this. Even thttpd doesn't seem to get this right.

I assume that you want to limit bandwidth that your customers use because the bandwidth to your server(s) is limited (i.e. you don't have a 100mbit connect to the internet). In this case, Apache modules will not do what you want. Someone puts up a 10mb file. That file gets downloaded and uses up all of your outgoing bandwidth. While it is being downloaded, the Apache throttle module refuses other requests. This is obviously not what you want.

So suppose you end up using Zeus, or find some other way to do real throttling. Now what do you set the throttle speed to? 5gb over a month averages a little less than 2k/sec. Say you set it higher, like 20k/sec, and there are ten connections downloading that user's files (which can easily happen with certain browsers). What does the average clueless user or webmaster think? They don't understand throttling. They just think that the website is slow and that your service sucks.

We would throttle down user's sites when their bandwidth ran out. Customers did not understand that they had run out of bandwidth, even though they were notified via email. They just thought their sites were slow. We received a lot complaints about that.

We found that the best thing to do is to not throttle and to presell bandwidth cheap. Our different packages come with different amounts of bandwidth, ranging from 5gb to 180gb. After that, customers can purchase extra bandwidth (for $0.50/gb). Customers receive a notification via email when their bandwidth is running low and again when it is completely gone. When their bandwidth is gone, we redirect their sites to a page stating that they used up all their bandwidth.

This solution is simple and it works. Customers always know how much bandwidth they have left and can buy more at anytime. We never have to worry about users running up a huge bill and not paying it, since everything is prepaid.

However it is also possible to achieve near ideal
scalability over multiple CPUs with a state engine based model:

Zeus CPU Scalability

Is called zeus

Great. So the Apache group has once again proven that they can deliver both a slow and insecure web server. How many more security holes will Apache have before it is "secure"? And when will Apache deliver truly high performance by having a non blocking I/O model?

What are our choices for web servers on UNIX platforms? Unfortunately, not many good ones. It looks like if you want speed, fast dynamic content and lots of configurability then Zeus Web Server is the only real option. The downside is that it's not open source and has a hefty price tag (although it is well worth it).

Boa is a nice, simple, fast web server that supports dynamic content through CGI's (so not much performance). publicfile's httpd is about the ultimate small, simple, fast and secure web server that supports only static content. If you must have a secure web server, this it (for example, defcon.org uses it). While it is a blocking server, it's small size (two data pages) should lead to performance comparable to that of larger, non blocking servers.

TUX is the main performance competitor to IIS.

Uh, no. That would be iPlanet, thttpd and Zeus.. Especially Zeus.

TUX is a cute proof-of-concept, and if RH can get some leverage over MS by patenting it, I'm all for it. But let's not kid ourselves about who IIS' competitors are.

Elgon

I've been using Apache 2 on Linux and FreeBSD for about 2 months now (...), and IMHO it is really going to rock the server world.

This isn't meant to be a flame, but a genuine complaint of the Apache web server that I haven't seen adequately addressed anywhere. How can Apache claim to be a modern web server if it continues to use an outdated request model? Having a separate process or thread for each request is completely unnecessary. Even for a site with dynamic content, the majority of the requests will be for static content (images). So why use up system resources when not necessary?

A request for static content is essentially just moving data from one file descriptor to a socket, something that sendfile(2) can be used for on operating systems that implement it. If a single system call combined with a select(2) loop can handle the majority of the requests, then why is each request tying up a process or a thread? When reading the Apache mailing lists, you get answers such as "it's too difficult for other programmers to extend the server", "processes or threads don't have to be expensive depending on how the operating system implements them", "everyone is happy with how it works now", and "Apache is meant to be correct first and fast second". None of these address the issue that Apache's request model is flawed, and it will never be high performance until it is corrected.

Additionally, the Zeus Web Server is well implemented and doesn't suffer from any of the problems that seem to keep Apache from being implemented correctly. It's also better than Apache in every way, ranging from performance to configuration (with the exception of not being open source). Zeus did everything right and built a great web server. Years later, Apache is just now getting their next version into beta, and it seems to be just as fundamentally flawed as the first version. If there is ever an open source web server as high quality as Zeus, then it more than likely won't be Apache.

Apache would be MUCH faster if the Apache developers would give up on the outdated and innefficient method of using a separate process per connection, and went with a non blocking I/O model like Boa, thttpd or Zeus. A non blocking I/O model is much better, from many standpoints. It places the I/O handling back in the kernel where it belongs, reduces memory usage and drastically increases speed.

I've talked to a lot of people about this issue, and spent a lot of time reading through the Apache developer mailing list. The main reasons that come up is that Apache is meant to be correct first, fast second, and that it is harder for people to extend Apache because it makes the code more complicated. The first reason is invalid, because it's quite possible to make a web server correct and fast at the same time. The three web servers I mentioned prove this. And there are several more non blocking web servers out there. The I/O is a very small part. Given a proper design, everything else can easily work with that model. Extending it is not made any more difficult, because one would very rarely, if ever, modify the base I/O model. You have normal HTTP and HTTPS, and that's it. Anyone who would be extending that critical portition of the web server should be able to understand the conceptually simple concept of non blocking I/O, especially as it is explained very well in a variety of sources.

IIS and Apache aren't the only one in the market. There are a lot of other very interesting web servers, especially Zeus.

Zeus is a non-forking server (at least for static pages). It's extremely fast, it performs even better than thttpd, while being more secure and with plenty of features. A single server running Zeus can easily replace 3 servers running Apache with the same content.

Zeus has an excellent web-based administration interface. The only fact that you can group sites can make you save a lot of time (group them by customers, then to disable all sites of a customer, one click is enough. No need to parse an ugly httpd.conf file) .

Zeus is designed for clustering (to add a machine to a cluster, one click is enough) .

Zeus works on a lot of operating systems (still waiting for the OpenBSD 3.0 version, though) .

Zeus supports frontpage, php, perl, etc. There's also a perl script to convert an existing Apache configuration to Zeus.

Ah yeah, Zeus isn't free software, though. Neither is IIS.

You may also be able compile PHP as a FastCGI program, you could then run several external FastCGI's as different users and configure Apache to run the particular script with a particular FastCgi program. I have no idea how to do this with apache, as I use Zeus myself.

If Apache 2 does have a way to switch users for PHP scripts, it will not be secure. Under UNIX, once you have dropped your permissions you can never gain them again. The work around is to have 'real' and 'effective' users that programs run as. As long as you only change your efective user, you can re-gain permissions, but anything can regain permissions. You can also only change users when you are root. This would be a big security hole, in that if there was a buffer overflow attack root could trivially be optained by anyone.

security, performance, configurability - pick 2

So TUX is about 3 times faster than Apache?
Woohoo! Zeus is about 3 times faster than Apache as well, but doesn't compromise security by running in the kernel.

Apache's process model sucks badly (having a single process (or even a single thread) per connection is utterly wasteful of CPU resources when you can use non-blocking IO (like Squid) to handle tens of thousands of simultaneous connections from a single single-threaded process). You can get 95%+ of the performance benefits of TUX by writing a userspace web server with a sensible process model. There's absolutely no need to start delving around inside the kernel.

This is the principal reason that Zeus has dominated the SpecWEB benchmarks for the last 5 years; if you're after a fast web server, Zeus is a sensible alternative to TUX.

Zeus Load Balancer is an excellent product. It scales hugely well, has excellent backup and works transparently across practically any TCP/IP protocol (be it www, smtp, nntp, or whatever). I've heard nothing but good things. It can also handle distributed SSL processing. Very cool and easy to admin product.

First of all, you will not win much with push, unless you use some sort of multicast. I guess, this is hardly possible, but you can think of it. Second, you can utilize async I/O web server. With web server like Zeus you will have 10000 sockets rather than 10000 threads. I didn't check it out, but this supposedly can be done with a single box. Third, since you are dealing with applet, you can use CORBA deferred synchronous request/response, wich possibly does exactly what you want.

In terms of performance, you'll find Zeus (http://www.zeus.com) is considerably faster than Apache but is pretty close to a drop-in replacement for it. It costs real money, but the performance gains are almost certainly worth it for a high-traffic site like /.

Works on various Unices. It might be pricy for a school (no price available but I expect it will cost you) but you might at least want to try the free evaluation copy.

No no no. As has been said before, don't use apache, use zeus. On both NT & Linux. The purpose here is supposed to be to test the underlying OS, not the web server. If you use apache for linux, you should use apache for NT, and you can't do that as apache for NT isn't up to par with apache for linux.

Also, they say that linux folks may be present, but will they pay linux people's travel costs and missed time at work for those like Linus whose jobs are not linux "enterprise" related?

What I'm wondering about is, what if the linux community does respond, and they have 4/500 people show up as members of the linux community to oversee the testing? hehehehehe.

Quite frankly, I think that MS should have challenged a linux vendor to come forward for the testing.