Apache 2.4 Takes Direct Aim At Nginx 209
darthcamaro writes "The world's most popular web server is out with a major new release today that has one key goal — deliver more performance than ever before. Improved caching, proxy modules as well as new session control are also key highlights of the release. 'We also show that as far as true performance is based — real-world performance as seen by the end-user- 2.4 is as fast, and even faster than some of the servers who may be "better" known as being "fast", like nginx,' Jim Jagielski, ASF President and Apache HTTP Server Project Management Committee, told InternetNews.com." Here's list of new features in 2.4.
Noticeable improvement (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Defaults still insane? (Score:5, Informative)
Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.
Re: (Score:3)
Re: (Score:3)
Unless I'm way off the mark, the vast majority of Apache out there (particularly in the environments I mentioned earlier) are running some sort of dynamic module like mod_php.
Re: (Score:3)
Re: (Score:2)
It's their responsibility because it's a (the?) typical deployment scenario for their software.
Re: (Score:2)
Re: (Score:3)
Actually, you might argue also that it's the distro's fault, since they typically determine the defaults deployed applications will use.
Re: (Score:3)
By insane you mean low? 16GB of server ram in a hundred and some bucks. 150 is pitiful try adding at least one zero. Stop buying cheap virtual or low end desktops somebody calls a server and you will not have any issue with the default settings. These numbers were low a decade ago and have not changed since.
Re: (Score:2)
If you need 1500 concurrent users connected to a server to handle your traffic, and you don't have persistent connections for AJAX or large file downloads, I assume you're handling one or two billion pageviews per day?
The rules do change a bit when you start scaling horizontally and your bottlenecks aren't in the same place, but if you need to handle that many concurrent connections on a single server, you've probably got a nasty bottleneck somewhere else that's causing your requests to take way too long to
Re:Defaults still insane? (Score:4, Insightful)
But if you're renting capacity from a virtual hosting provider, adding more RAM sends your monthly costs through the roof. Since tens of thousands of little websites run in that type of environment, it's a serious problem for a lot of low and lower-middle tier companies. I'm starting to think cloud hosting for small companies only makes sense financially if they write all their server code in C and C++. (Scary)
I don't think it really matters what Apache makes the defaults, as long as there's plentiful, clear documentation on what the configuration parameters mean and how to make an educated guess as to what values you should set for your own deployment.
Re: (Score:2)
if you need 1500 concurrent connections, then you REALLY should look at event driven web servers [daverecycles.com].
BTW, for comparison, with cherokee and a uwsgi python uGreen app (used for ajax long-poll comet events) I've successfully tested 1500 connections on a 256mb vserver. It started to go a bit slowly then (1-2 seconds delivering to all clients), but it worked. In normal use I see maybe 150-200 connections to that daemon, and that works splendidly.
It's the difference between a restaurant having a waiter (and in some
Re: (Score:2)
If "Your own hardware" includes a proper hosting building, ventilation, physical security, energy control & backup system, that's is going to be much more than a few hundred $$.
Re: (Score:3, Insightful)
From reading your post, it seems that the biggest cause is people trying to run web servers who don't know how to and probably shouldn't be.
Re: (Score:2)
That's not entirely uncommon, no.
Re: (Score:2)
Firefox auto-configures settings such as how much memory it can use for caching fully rendered pages. Couldn't Apache in theory look at what mods you have installed, and how much system memory you have and then auto-tune default settings?
Re: (Score:2)
It could; server admins might not like it, but "reduce maxclients" sounds like a better failure scenario to me than "trigger kernel OOM killer"
Re: (Score:2)
I think if they got to the point of adding auto-configure it would be like admitting they have a problem but not actually addressing the problem. Firefox can make a lot of assumptions about how it is going to be used. I don't think there's a realistic way to
Re: (Score:2)
So you expect to run Apache without configuring it to your environment?
Defaults are defaults. If you don't have a default configuration, you need to change it.
Re: (Score:2)
I expect Apache to ship with defaults appropriate for the typical user. In my case, I configured my way to a different web server half a decade ago, due to Apache's various shortcomings.
Re: (Score:2)
I doubt there is a "typical user". Everybody thinks they are a "typical user" but everybody is different. Apache runs on everything from old laptops to large data centers.
It's naive for anyone to install Apache and to assume the defaults will be right for their environment.
"If you assume, you can make an ass out of u and me."
Re: (Score:2)
Re: (Score:2)
"Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server?"
Yes. I've been told now Apache comes with mod_emacs so you can edit the config file to your leisure... from within apache itself!
(of course, for this to work they had to disable the built-in web server and kitchen sink standard emacs comes with).
Re:Defaults still insane? (Score:4, Informative)
There are a handful of workloads that can justify that sort of concurrency, but they're few and far between. Web applications with persistent connections (which you're obviously not doing with that amount of RAM), or serving up large files for download, that sort of thing. The typical case of a LAMP stack almost never requires it, and enormous loads can be handled with levels of concurrency orders of magnitude smaller than what you've got.
People normally thing they want to handle tons of people at the same time, but handling 10x more client requests simultaneously typically means each one takes 10x longer to process; there's no performance advantage, and all you've managed to do is burn RAM.
I won't say that your workload doesn't justify that sort of concurrency, because I don't know what your workload is, but 150 is not a reasonable default for the vast majority of applications. Certainly not for most LAMP installations, where 512MB of RAM is typical, and more than a gig or two is rare.
Re: (Score:2)
People normally thing they want to handle tons of people at the same time, but handling 10x more client requests simultaneously typically means each one takes 10x longer to process; there's no performance advantage, and all you've managed to do is burn RAM.
Hoo-raay! So many just plainly fail to understand that. For one web site I'm running, we have an event-driven web server that talks to an app backend. It's maybe 50-150 active users on it, but a lot of dynamic stuff happening. The server have 2 cpu's. For two cpu's I figured 4 threads (some overhead with network connections, pushing data around, and occasional upload) were okay for the app backend. The other admin involved asked "Why only 4? Couldn't we bump it up to at least 100?" - What would be the point
Re: (Score:3)
I wasn't aware that the world's largest server providers were "my mom's basement". If so, perhaps I should move back home, because that sounds like a fucking awesome basement.
For every enterprise customer like you with big iron, there are many more smaller servers. It's like the graphics card industry. Enthusiasts drive the high-end cards, but the vast majority of the market (and profit) is made off the average customer and their iGPU or other low-end part.
Re: (Score:2)
Big Iron? Now days a Super Micro box with 24GB of ram can be had for a $1000... Ram has gotten really cheap. $2500 or so for a box with 64GB.
Re: (Score:2)
That's nice, if you're colocating. If you're buying a dedicated server, from, say, SoftLayer, going from 2GB to 24GB will cost you an extra $6600 per year.
If you're hosting with Linode, who are an excellent top-of-the-market VPS host, they'll charge you roughly the same.
If you could handle the same load with a tenth the RAM, then the cost of the 24GB boxes becomes wasteful.
Re: (Score:2)
Re: (Score:2)
You really think the extreme majority is running Apache on 512M RAM? Show me some numbers, and I'll believe you.
I was running apache on a cheap virtual server with 512M ram. That was until I moved to nginx.
Re: (Score:3, Interesting)
Yes, I do actually. Most Apache installations are going to be at dedicated and VPS server hosts, due to the sheer number of customers in that market, and they're typically going to have tens of thousands of servers with far far less than 10GB of RAM.
150 max clients is enormously too high for a LAMP stack, or serving static content (unless you're dealing mostly in very large files). Most cases where I see people running that sort of concurrency with enough RAM to back it up are caused by people misconfigurin
Re: (Score:2)
Basically. I'm generalizing a lot, and a lot of this stuff matters much less if you've decoupled PHP (or similar) from your webserver and are running apache with something other than mpm_worker, where it takes one process per request, but that's the idea. There are workloads that legitimately do need massive concurrency.
The point isn't maximizing your Apache configuration to take advantage of available RAM, it's having extra RAM in the first place when it's not needed to handle the load. I've seen way too m
Re: (Score:2)
That would be my expectation too.
The smaller numbers of high traffic sites with lots of hardware are going to be monitored and tuned by experienced sysadmins anyway - no matter what the defaults are. ie they won't be using the default settings.
The far more numerous low traffic sites on virtual servers running mostly off the shelf
Re: (Score:3)
My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".
Shouldn't your hosting provider be doing this for you, or shouldn't you be doing this on install? This thread has been going on and on over a handful of config options. So you need configuration management. The apache config is flexible enough and unlike sendmail completely readable and comprehensible.
Re: (Score:2)
No, I'm saying that handling 150 *concurrent* clients on Apache requires an excessive amount of RAM. Because mpm_worker will spawn 150 different processes to do that, and in reality, you rarely need to handle 150 concurrent sessions, even if you've got 1000 simultaneous users. Why? Well, if 1000 people are browsing a forum, they're not all constantly hitting the server, and even when a good number of them do, there's nothing to be gained from trying to serve too many of them at the same time; better to hand
A bit bitter are we? (Score:5, Informative)
"We also show that as far as true performance is based - real-world performance as seen by the end-user- 2.4 is as fast, and even faster than some of the servers who may be "better" known as being "fast", like nginx," Jagielski said.
What's with the quotes? Other servers have proven to be faster, lighter weight, and more scalable than Apache for a long time. Don't be bitter because you fell behind. Be happy that you're finally catching up.
Re: (Score:3)
Re: (Score:2)
Apache is the swiss army knife of web servers (Score:2)
Frankly unless you are doing something very specialised with your app, Apache is probably what you are looking for and even if you are doing something very specialised it can probably take a creditable stab at it.
Re: (Score:3)
no, it isn't right to use these quotes when Apache 2.2 (which is what is currently available for production) gets destroyed by nginx / lighty in specific tasks by upto 800%.
Apache 2.4.1 is the version currently available for production [apache.org], but don't let pesky things like facts stop you.
Re: (Score:2)
Why would 2.2 getting destroyed matter when 2.4.1 is the current prod version?
Re: (Score:2)
1. I'm aware of systems handling 12k+ requests per second, on Apache. Not terribly exotic ones either.
2. Forking? Really?
3. PHP... Now I understand.
What we need (Score:4, Interesting)
We need a fully async web server, like nginx, but with *full* support for fastcgi/http1.1 and connection pooling to the backend servers.
In case some people don't know, nginx uses http1 to connect to the servers, which means a new connection for reach request. Same thing for FastCGI. nginx opens a new FastCGI connection for each request, then tears it down once done, even though FastCGI supports persistent connections and true multiplexing.
nginx is awesome and I love competition, especially between opensource.
Re: (Score:2)
HTTP/1.1 proxying is currently available in the development version so if needed you can use that. [nginx.org]
Re: (Score:2)
We need a fully async web server, like nginx, but with *full* support for fastcgi/http1.1 and connection pooling to the backend servers.
Hmm, I wonder, would something like Mongrel2 fit your bill? You don't get FastCGI, but the communication protocol does not seem to be too complex to implement.
Re: (Score:2)
If nginx can't do FastCGI properly, it is far from a replacement for Apache. If you want to run one web server, whether in a single configuration or several complementary ones, Apache continues to be the best choice overall. However, I imagine some setups would find the best tradeoffs with nginx out front and Apache talking to the FastCGI servers.
Re: (Score:2)
mod_fastcgi doesn't support multiplexing either. Why would you make an incorrect comment when you can just Google something simple like this?
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html [fastcgi.com]
"The FastCGI protocol supports a feature, described in the specificiation as "multiplexing", that allows a single client-server connection to be simultaneously shared by multiple requests. This is not supported."
Re: (Score:2)
mod_fastcgi doesn't support multiplexing either. Why would you make an incorrect comment when you can just Google something simple like this?
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html [fastcgi.com]
"The FastCGI protocol supports a feature, described in the specificiation as "multiplexing", that allows a single client-server connection to be simultaneously shared by multiple requests. This is not supported."
You seem to be confusing multiplexing with persistent connections, which mod_fastcgi and mod_fgcid certainly do support. Since you're such buddies with Google, I'm sure you're aware that the entire point of FastCGI is to avoid having to create a new application or script process and connection to it for every HTTP request. These persistent processes and connections are what both mod_fastcgi and mod_fcgid make easy and if nginx cannot do the same, it is not a good replacement. Why would you make an incorrect
Re: (Score:2)
The current stable release of nginx does support FastCGI fully, just not the latest FastCGI spec that added a bunch of new abilities to further streamline the FastCGI protocol and reduce bottlenecks further. It also supported upstream proxy requests, but it only used HTTP 1.0 requests to them to keep the code simple.
Apache 2.2 didn't support those latest features either, FYI.
The latest development versions of nginx *DO* support more of the latest FastCGI specs/features now, and also adds HTTP/1.1 (I.E. pipelining) requests to upstream servers when needed, so if nothing else nginx can now mask/convert multiple HTTP 1.0 requests into a single stream of HTTP 1.1 pipelined requests.
I wasn't referring to version of HTTP, but to the previous claim that nginx makes a new connection to a FastCGI server for every request. I don't know enough about nginx to prove or disprove that claim, but if it's true, nginx is quite deficient compared to Apache's mod_fcgid.
Re: (Score:2)
Fixes I'd rather have (Score:4, Interesting)
I'd rather have better control features, such as completely redoing the vhost matching method.
Ubuntu vs Gentoo (Score:5, Insightful)
IANA web admin, but from what I have learned from playing around with both Apache and Nginx is that they serve different markets.
Nginx is a small, fast, reliable web server that is great for virtual machines, home users, newbies (like me), etc. It is simple and "just works" because it make sense. Nginx is the Ubuntu/Mint of the web server world.
Apache is a massive, feature rich, highly tunable, beast that can inter-operate with everything. This is an enterprise class (or at least very serious workload) web server. Designed by people who know what they are doing for people who know what they are doing. Apache is the Slackware/Gentoo of the web server world.
If you need a web server to get a job done, use Nginx. If the web server is your job then Apache. The key is how much time you have to spend figuring out how to customize Apache just right vs. how much those customizations are worth.
Re: (Score:2)
Apache is the Slackware/Gentoo of the web server world.
That's probably very true [funroll-loops.info]. Thanks for pointing that out :)
Re: (Score:2)
Yes, I can see you are not a web admin. Your post is just your (wrong) opinion. Both require the same amount of expertise to configure.
Performance? RAM usage? (Score:2)
Oh come on guys!
Every software has it's place to run. httpd, IIS (sorry for mentioning this one), lighttpd, tux, nginx,
Still comparing? Go buy 1 GB more RAM. Or say "sorry, It's easier for me to work with nginx, because apache is too heavy for my brains".
How much more RAM does it take for high loads than nginx?
[root@node3 ~]# ps_mem.py |grep -E "RAM|httpd|php"
Private + Shared = RAM used Program
202.6 MiB + 50.1 MiB = 252.7 MiB httpd (190)
940.2 MiB + 831.4 MiB = 1.7 GiB php-c
Re: (Score:2)
I'm curious, what MPM are you using? Event MPM?
Re: (Score:2)
Wait.. You're running 190 php processes on two cores? Are you serving static files with php, or using it to query a db on a different machine? And if so, is your DB so slow that you need 190 concurrent requests to get it to max out? Data that can not be cached with memcache, or pages that can't be cached with varnish?
Please, I'm honestly curious what all those php processes are doing, which involves sitting idle 90% of the time. Could you enlighten me?
Re: (Score:2)
Sounds like a fun and interesting system, and a fair bit beyond what I'm usually working with!
Yeah, shared hosting might explain some reasoning behind it :) Running different php processs under different userid's. Still.. "some virtual hosts are running over 30 processes sometimes" - that doesn't really address the main question. With only two logical execution units (two cores), and (rounding off) 200 php processes, 2 cpus over 200 processes = 0.01 cpu slice per process? Not calculating httpd processing..
Re: (Score:2)
For me it still sounds pretty weird.. :)
But yeah, ram will help a lot, both for caching files, and especially if you use an opcode cache, like APC [php.net] (which can also have a hot cache in ram).
The more ram, the less it has to wait for the horribly slow disk to spin around, and thus faster answer. Great Win (TM) :)
I'm still waiting for reasonably priced SSD's becoming normal in servers. *sigh* Being able to use an SSD for caching hot data automatically, without killing it instantly.. Sure, RAM is faster and cheap
Re: (Score:2)
For computing: I know one guy who wrote online game completely in PHP with MySQL backend for one company and 12 cores were hardly serving ca. 400 users: each client was sending and receiving 1 message per second - status updates, moves, server responses with statuses of other users and calculation of games. Surely, they've decided to rewrite it in C++, he did. Surprise: CPU usage is almost the same, I couldn't believe it, I've double-checked protocol and yes it is, without apache :D
the bottleneck was mysql, have them try it with a real database like DB2, they will see that the rewrite paid off...
Re: (Score:2)
How much more RAM does it take for high loads than nginx?
202.6 MiB + 50.1 MiB = 252.7 MiB httpd (190)
940.2 MiB + 831.4 MiB = 1.7 GiB php-cgi (189)
From my own site, doing 1500 hits/sec:
# python ps_mem.py | grep -E "nginx|php"
16.4 MiB + 1.2 MiB = 17.6 MiB nginx (9)
186.4 MiB + 14.7 MiB = 201.1 MiB php5-fpm (44)
For a site hosted on a VM, a 2GB setup would be 8x as expensive as a 256MB setup :-P (I presume we're both hosted on bare metal now, so my setup simply leaves more space for cache; but nginx's slimness did allow me to to stay on a cheap VM until recently)
1 GB RAM vs delay + reading books, code and googling.
If you're already an apache expert and an nginx noob, then sure, sti
Node.js Is Bad Ass Rock Star Tech (Score:2)
What's missing in this debate is the fact that Node.js Is Bad Ass Rock Star Tech [youtube.com].
Re:Apache Never Again (Score:5, Insightful)
So, your claim is that software can never improve?
Re: (Score:2)
Anonymous Coward switching to NginX would prove software can improve. The question is, does it need to be done by rethinking and starting over from scratch.
Re: (Score:3)
I don't think the op was saying that, just that switching to nginx was a significant improvement over Apache.
At one place I worked, I increased our server capacity by 3 times, simply putting nginx in front of apache as a reverse proxy. Another place I replaced apache with nginx and cut memory requirements by over half. There are some things nginx doesn't do well, but nginx is so good at what it does it's still worth using the two together.
From my reasonably extensive experiences with both, Apache comes acro
Re:Apache Never Again (Score:5, Insightful)
I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
Quick translation into English: 'I am too clueless to run a webserver, but wish to get First Post'.
Re: (Score:2, Insightful)
Quick translation into English: "I like my sendmail-esque configuration just fine. It's job security."
Re: (Score:2, Insightful)
I think that may speak more about the sort of jobs you get hired for and the people you work with, rather than Apache itself.
The Apache configuration layout that Debian uses combined with Puppet or Chef is goodness.
Re: (Score:2)
Indeed the config is a bit of a mess. Although most distributions have made it much more modular and easier to maintain, the psuedo html doesnt really work that well. It feels inconsistent and verbose.
Re: (Score:2)
I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
Care to elaborate? I'm faced with that decision right now.
Re: (Score:2, Informative)
I use Apache Server with mod_jk.so to redirect requests to Tomcat and mod_ssl so that Apache Server is responsible for channel encryption. If you have to do something like that your best bet is Apache Server, not Nginx.
Re: (Score:2)
Re: (Score:2, Insightful)
No, nginx is slower when talking to Apache Tomcat than Apache server is, check your mouth at the door.
Re: (Score:2)
Re: (Score:2)
Nginx is WAY faster for the same system resource and it's easier to configure.
I'm not saying apache is bad, just nginx is better. I'll not be going back to apache.
Re:Apache Never Again (Score:5, Interesting)
I think this is a fairly common sentiment towards Apache from developers who have to deploy their own stuff. I've certainly been in that camp more than a few times in the past. We're talking about:
- RAM usage
- Just being slow to push out simple files
- mod_php being the worst thing ever written
- mod_python disproving the last statement and taking the crown
- Various FastCGI/WSGI toolchains just not being up to scratch either.
I moved to nginx and Cherokee and suddenly configuration was both compact and modular and the settings seemed to make a real difference. RAM usage is completely minimal and performance is scorchingly hot. In more than one case I took an Apache box, switched Apache out and we were using half the RAM for the same jobs, and getting better performing websites, with less configuration.
I'm certain Apache could have been tuned but I don't think it's unreasonable for a developer to blame the software if you have to do a three year BSc in Apache Administration just to get something equivalent to 30 minutes playing in nginx.
I truly do hope that things are improving (competition is key in this environment!) but now I've left Apache on multiple servers, they're going to need to do more than just say "If you tune it, it can now match nginx speed", because my time is valuable too. I'm not going to jump back in until for most deployments it "just works".
Re:Apache Never Again (Score:4, Interesting)
The code also deserves a special mention: it's like when you look under the hood of your car/computer for the first time, where everything is clean, all cables are numbered and arranged meticulously. This is a good old C code that doesn't need extra comments to be understood.
Apache improved? Show me the comparison charts between Apache and Nginx, in a many-users multi-cores-cpus and loaded configuration. To be honest, even if Apache would be a bit faster using a bit less memory than Nginx (while I have some doubts about that), I'd still be reluctant to go back to Apache and its setup.
Re: (Score:3)
I'm certain Apache could have been tuned but I don't think it's unreasonable for a developer to blame the software if you have to do a three year BSc in Apache Administration just to get something equivalent to 30 minutes playing in nginx.
I truly do hope that things are improving (competition is key in this environment!) but now I've left Apache on multiple servers, they're going to need to do more than just say "If you tune it, it can now match nginx speed", because my time is valuable too. I'm not going to jump back in until for most deployments it "just works".
What makes you think that extremely complex piece of software is supposed to be easy to setup, by just about everyone?
Developers can do their development on default setup, I don't see a problem with that.
If you need to use it on production setup (or replication of production setup), then get people who know what they're doing to configure it.
Re: (Score:2)
Apache isn't the application, it the platform that applications are running on... there are many exampled for complex under the hood but easy to manage platforms..
The issue is that the "Default" setup is not performing as well as the "Default" of another product offering the most of the same services.
Not sure what IT department you work in, but many have been cut all to hell in the last few years meaning fewer Experts can be hired and your a left with a small team trying to do everything.
Re:Apache Never Again (Score:4, Insightful)
What makes you think that extremely complex piece of software is supposed to be easy to setup, by just about everyone?
What makes you think everyone needs an extremely complex piece of software when their needs are often quite simple?
Apache is big and complex, nginx is small and simpler. Often one works better than the other for a particular person's needs. If someone finds Apache difficult to set up and finds nginx to be easier, then telling him to get someone to set up Apache is not the answer since he already already has the answer he is looking for. If Apache wants to be that answer too, then they need to find a way to simplify configuration.
Re: (Score:2)
Re:Apache Never Again (Score:5, Insightful)
+1. Really, it's not even about performance or that Apache guys are bad at software. Far from it. The real crux is that Apache has become the Kitchen Sink of webservers. It can do *anything*, and there's always a complexity cost for that. Nginx can't do everything, but it's a really efficient and minimalist implementation of what 97% of modern deployments actually need, and none of the things they don't.
In some meta-sense, all software goes through this cycle: You're the best, everyone uses you, everyone files niche feature requests, you actually implement all of the niche features, and next thing you know 10 years later you're the Kitchen Sink implementation of domain X, and someone comes along and throws out all the irrelevant bullshit and makes a leaner implementation of just what matters *today*.
IMHO, the answer is that dropping features needs to be as easy as adding them. Too many software projects/architects have an easy-in, hard-out policy on features. "We can't drop feature X, it's been there for years and some crazy people in siberia still use it". It's ok to drop features on major-cycle releases. Perhaps even necessary for long-term project health.
All that and the configuration (Score:2)
Re: (Score:2)
Apache MPM Worker + FastCGI with fcgid (Score:3)
The mistake is trying to use mod_php with a heavy PHP application, such as a a complex Drupal site, without a reverse proxy such as Varnish or nginx.
One trick I have been using for a few years is using Apache as a threaded server, with MPM Worker, and FastCGI but with fcgid, not mod_fastcgi. Works exceptionally well. For static files, Apache is now lightweight and does not use much RAM.
For details, see my article on Apache MPM Worker with fcgid [2bits.com].
Re: (Score:2)
The performance hit for doing that is pretty bad - any time you hit a .php file the system has to go start up a new PHP interpreter program. (This isn't specifically a PHP thing, plain old-school cgi is the slowest way to run anything that needs an interpreter).
I've gotten quite fond of php-fpm (an "internal" implementation of a fastcgi provider included with PHP), and as a bonus once it's set up, you can switch between cherokee, nginx, apache, lighthtt
Re: (Score:2, Interesting)
I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
You struggled to use Apache?
I appreciate you telling me this. You've enlightened me to add something to my hiring practices. Now I know to ask a simple Apache configuration question when I Interview someone. I definitely don't want to hire someone that has trouble using something as simple as Apache.
Re:Apache Never Again (Score:4, Insightful)
I definitely don't want to hire someone that has trouble using something as simple as Apache.
Holy crap, do you even use Apache? At my job, I get to roll my own from source and I own every line of httpd.conf and each of our vhosts.
Simple is not the word I would use to describe it. "Specialized" is much more like it.
Re: (Score:3)
Apache is "simple" in the same way that PHP is: it has excellent documentation because it has to or else no one would ever be able to use it. I've been using it professionally since the late 90s and am reasonably happy and comfortable with it, but I still have to RTFM every time I want to do something non-trivial.
Re: (Score:2)
I appreciate you telling me this. You've enlightened me to add something to my hiring practices. Now I know to ask a simple Apache configuration question when I Interview someone. I definitely don't want to hire someone that has trouble using something as simple as Apache.
The problem isn't with "simple Apache configuration", the problem is when a manager thinks that only simple apache configuration directives are needed to set up their site to be secure, scalable, and stable. That's often not the case with Apache.
Re: (Score:2)
Historically Apache hasn't been great when it comes to performance. I run a number of busy web applications and having migrated from Apache to Lighttpd and then to a combination of Lighttpd and NginX I can tell you that everyone espousing Apache simply hasn't had to scale. Apache is fine you are running one or two servers with minimal load, beyond that is when you start to see problems.
You can easily do tens of millions if not hundreds of millions of light requests per month with minimal scripting and a
Re:First post (Score:5, Funny)
You must be nginx with such a fast response.
Re: (Score:3, Funny)
Re:Apache (Score:5, Funny)
Get off the rant, you were too stupid to figure out Apaches awesomeness so it spit you out, NginX took you in as it takes everyone in.
Well, I like my http servers like I like my women: fast!
I too like my webservers like I like my women: Insecure and full of holes waiting to be exploited. That's what I run Microsoft's IIS.
Re: (Score:2)
Re: (Score:3)
And how would you do it w/o one thread or process per client? Multiplexing?
We actually need multiple web server models. Processes are needed for multi-user environments for security reasons. But that impacts performance for single-user environments. OTOH, Apache does process based stuff all wrong, too (they do execve() for CGI and that is where the performance dies).
Re: (Score:2)
And how would you do it w/o one thread or process per client? Multiplexing?
One thread (and maybe one process per CPU) and non-blocking IO (with kqueue, /dev/poll or similar) is the way to go if you want very high performance, especially if you might have large numbers of idle or slow connections (as with keep-alive). The level of resource use is vastly, vastly lower and there's never any synchronization or scheduling overhead. I've written high-performance servers using this model and it works very well.
Re: (Score:2)
We run MOD_PHP with Apache 2.2, should we expect to have MUCH lower memory usage - currently the servers have 8GB of memory and are limited by huge memory per apache connection.
Sounds like you need to check what's happening in your PHP code.