Apache 2.4 Takes Direct Aim At Nginx

← Back to Stories (view on slashdot.org)

Apache 2.4 Takes Direct Aim At Nginx

Posted by timothy on Tuesday February 21, 2012 @04:33AM from the competition-drives-progress dept.

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.

209 comments

Min score:

Reason:

Sort:

First post by Anonymous Coward · 2012-02-21 04:34 · Score: -1

First!
1. Re:First post by Anonymous Coward · 2012-02-21 05:03 · Score: 5, Funny
  
  You must be nginx with such a fast response.
improve the noob XML style config by Anonymous Coward · 2012-02-21 04:35 · Score: -1

That mix of XML and a config file is a mess, please do something modern ...
Apache foundation sucks, it's full of Java Losers who of course are the worst programmers EVER
Apache Never Again by Anonymous Coward · 2012-02-21 04:37 · Score: -1, Flamebait

I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
1. Re:Apache Never Again by TheCRAIGGERS · 2012-02-21 04:41 · Score: 4, Insightful
  
  So, your claim is that software can never improve?
2. Re:Apache Never Again by Simon+Brooke · 2012-02-21 04:43 · 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'.
  
  --
  I'm old enough to remember when discussions on Slashdot were well informed.
3. Re:Apache Never Again by sribe · 2012-02-21 04:45 · Score: 1
  
  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.
4. Re:Apache Never Again by roman_mir · 2012-02-21 05:06 · Score: 1, 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.
  
  --
  You can't handle the truth.
5. Re:Apache Never Again by 0100010001010011 · 2012-02-21 05:07 · Score: 2, Insightful
  
  Quick translation into English: "I like my sendmail-esque configuration just fine. It's job security."
6. Re:Apache Never Again by OliWarner · 2012-02-21 05:19 · 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".
7. Re:Apache Never Again by pak9rabid · 2012-02-21 05:41 · Score: 1
  
  What a stupid thing to say. Nginx can do both of these tasks (SSL endpoint, reverse-proxy) well...probably even faster.
8. Re:Apache Never Again by Anonymous Coward · 2012-02-21 05:42 · Score: 1
  
  What, precisely, is "sendmail-esque" about the Apache configuration? If you're writing your httpd.conf in m4, you're doing it wrong.
9. Re:Apache Never Again by hcs_$reboot · 2012-02-21 05:47 · Score: 3, Interesting
  
  Nginx is not only the performance, it's also the configuration syntax ; everything looks much more professional, concise, and logically designed.
  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.
  
  --
  Slashdot, fix the reply notifications... You won't get away with it...
10. Re:Apache Never Again by Skapare · 2012-02-21 05:48 · Score: 1
  
  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.
  
  --
  now we need to go OSS in diesel cars
11. Re:Apache Never Again by Anonymous Coward · 2012-02-21 05:50 · Score: 1
  
  Okay, I'm not clueless. Apache works for some people, but not for me. I find Nginx to be much stabler and easier to configure all the way around.
  BTW, I don't read Slashdot enough to do the First Post thing. I wasn't even aware that mine was until you pointed it out.
12. Re:Apache Never Again by hlavac · 2012-02-21 05:58 · Score: 1
  
  Isn't mod_jk obsolete?? I thouht you are supposed to use mod_proxy_ajp, especially behind SSL...
13. Re:Apache Never Again by C_Kode · 2012-02-21 06:12 · 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.
14. Re:Apache Never Again by X.25 · 2012-02-21 06:13 · Score: 2
  
  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.
15. Re:Apache Never Again by archen · 2012-02-21 06:20 · Score: 1
  
  I don't think anything is as bad as sendmail, but I'm assuming he's referring to some rather obtuse configuration options in httpd.conf. The first thing that comes to mind are the psudo html tag blocks, that are nothing like anything else in httpd.conf. I think another problem is that every apache install I've seen (that I didn't set up myself) was basically the default config with every module enabled and stuff tossed in or commented out in a spaghetti clusterfuck.
16. Re:Apache Never Again by Anonymous Coward · 2012-02-21 06:26 · 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.
17. Re:Apache Never Again by Anonymous Coward · 2012-02-21 06:47 · Score: 1
  
  It doesn't support jk/ajp, but HTTP is supported.
18. Re:Apache Never Again by TheNinjaroach · 2012-02-21 06:49 · Score: 3, 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.
  
  --
  I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
19. Re:Apache Never Again by Anonymous Coward · 2012-02-21 06:50 · Score: 2, Insightful
  
  I think another problem is that every apache install I've seen (that I didn't set up myself) was basically the default config with every module enabled and stuff tossed in or commented out in a spaghetti clusterfuck.
  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.
20. Re:Apache Never Again by roman_mir · 2012-02-21 06:57 · Score: 1, Insightful
  
  No, nginx is slower when talking to Apache Tomcat than Apache server is, check your mouth at the door.
  
  --
  You can't handle the truth.
21. Re:Apache Never Again by BagOBones · 2012-02-21 07:13 · Score: 1
  
  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.
  
  --
  EA David Gardner -"... but the consumers have proven that actually what they want is fun."
22. Re:Apache Never Again by 1s44c · 2012-02-21 07:20 · Score: 1
  
  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.
23. Re:Apache Never Again by Anonymous Coward · 2012-02-21 07:46 · Score: 0
  
  bah bah bah, you so stupid me so smart meh meh meh.
  Idiot.
24. Re:Apache Never Again by Just+Some+Guy · 2012-02-21 07:56 · Score: 2
  
  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.
  
  --
  Dewey, what part of this looks like authorities should be involved?
25. Re:Apache Never Again by hawguy · 2012-02-21 08:20 · Score: 3, 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.
26. Re:Apache Never Again by hawguy · 2012-02-21 08:23 · Score: 1
  
  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.
27. Re:Apache Never Again by GioMac · 2012-02-21 08:35 · Score: 1
  
  What about using PHP-CGI on apache without mod_php?
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
28. Re:Apache Never Again by Anonymous Coward · 2012-02-21 09:07 · Score: 0
  
  mod_jk isn't obsolete, by far. If you're talking to a bunch of JVMs and need to perform routing that isn't supported in the three mod_proxy_balancer options (and runtime reconfiguration), mod_jk is a good choice. Two JVMs, round robin? mod_proxy_ajp, for sure.
  I think that a lot of the mod_jk users may go to either mod_proxy or mod_cluster as it matures.
29. Re:Apache Never Again by shadowmas · 2012-02-21 09:17 · Score: 1
  
  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.
30. Re:Apache Never Again by John+Courtland · 2012-02-21 09:20 · Score: 1
  
  Plus you lose the secure flag in HttpServletRequest if you don't use AJP proxying, so then you have to do some kind of stupid header hack or a second port or IP to provide the Java runtime with knowledge that your channel is secure (unless you are running 100% SSL, which isn't a bad thing imo).
  
  --
  Slashdot is proof that Sturgeon's Law applies to mankind.
31. Re:Apache Never Again by RajivSLK · 2012-02-21 09:46 · Score: 1
  
  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 bit of MySQL of a single core i7 box. If that is your scenario you simply won't understand what people are talking about when they say the performance sucks.
  When I switched I had over a dozen web servers serving billions of high workload requests per month. During peak usage times load would peak, back logs would increase, and response was starting to slow. We had our own custom Apache source tree and were constantly conducting experiments to tune and tweak the configuration. We used Lingerd and all sorts of complicated tricks and tweaks to squeeze every last drop of performance. Then, as a test, we switched to Lighttpd, default configuration, and guess what? Load absolutely plummeted. We dropped Apache like a bad habit. That was years ago and we have probably saved $100k in hardware and time since... Now we actually spend our time optimizing our Applications and never worry about what the web server is doing.
32. Re:Apache Never Again by Anonymous Coward · 2012-02-21 10:12 · Score: 0
  
  Snotty team heads rejoice.
33. Re:Apache Never Again by Anonymous Coward · 2012-02-21 10:25 · Score: 0
  
  Yup see mongo vs RDBMs. Same thing.
34. Re:Apache Never Again by Dr.Dubious+DDQ · 2012-02-21 10:53 · Score: 1
  
  Second this - I've grown to prefer Cherokee (ridiculously easy configuration, as fast as nginx, and 'copylefted' as well), though I have no complaint using nginx as well (I'm using nginx on a virtual server running an Ubuntu release that seemed to be having some trouble with cherokee with php-fpm for reasons I wasn't able to figure out.)
  
  --
  Hacker Public Radio is our Friend
35. Re:Apache Never Again by Dr.Dubious+DDQ · 2012-02-21 10:54 · Score: 1
  
  Apache is essentially the "sendmail" of web servers...
  
  --
  Hacker Public Radio is our Friend
36. Re:Apache Never Again by Dr.Dubious+DDQ · 2012-02-21 11:02 · Score: 1
  
  "What about using PHP-CGI on apache without mod_php?"
  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, lighthttpd, etc, or even some combination of them at the same time as long as they support fastcgi, without needing to do anything else to PHP configuration.
  
  --
  Hacker Public Radio is our Friend
37. Re:Apache Never Again by TheRealMindChild · 2012-02-21 11:37 · Score: 1
  
  I don't know why anyone listens to assholes like you. "I never had a problem so you must suck enough to be pinned to the shit of the profession" bullshit isn't a valid retort at all. It is bullying in hopes to win your online cock-affirmation.
  
  --
  
  "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
38. Re:Apache Never Again by gmhowell · 2012-02-21 13:50 · Score: 1
  
  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.
  'Special' is how they refer to the kids on the short bus as well (and Palin's and Santorum's kids).
  
  --
  Jesus was all right but his disciples were thick and ordinary. -John Lennon
39. Re:Apache Never Again by GioMac · 2012-02-21 19:43 · Score: 1
  
  The performance hit for doing that is pretty bad
  Why? nginx is also using CGI interface. Everything's the same.
  
  any time you hit a .php file the system has to go start up a new PHP interpreter program.
  
  Actually it depends on php side, not the web server:
  php-cgi - you configure how many processes you want to have
  php-fpm - automatic
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
40. Re:Apache Never Again by SausageOfDoom · 2012-02-21 21:55 · Score: 2
  
  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 across as a slow lumbering juggernaut designed to do everything, no matter the cost, whereas nginx was designed with nothing but speed and efficiency in mind.
  I'm sure Apache can improve, but short of a total rewrite reflecting a change in their approach, I'd be doubtful it can overtake nginx.
41. Re:Apache Never Again by Anonymous Coward · 2012-02-22 00:53 · Score: 0
  
  Wind your cock in. The guy outright claimed:
  
  every apache install I've seen (that I didn't set up myself) was basically the default config with every module enabled and stuff tossed in or commented out in a spaghetti clusterfuck.
  Which is demonstrably utter horse shit. You'll note the irony in accusing me of being the one who is apparently playing the "everyone but me" card, yet he's the one who wrote that parenthetical "that I didn't set up myself" cock-wave.
  
  Got that? Good.
42. Re:Apache Never Again by justforgetme · 2012-02-22 03:31 · Score: 1
  
  Having experienced the easy in never out thing I have to add some sentiments to this:
  when you expand a framework to include more features you always end up doing
  various abstractions, expansion endpoints, etc... these things once in can't be
  removed without effectively rewriting the whole application or a big part of it. The
  problem with partial rewrites is that they usually get quite complex if you want to cut
  out exactly all the cruft and usually end up in failures.
  So - more or less - get it over with. Either do a blank sheet rewrite or just start a
  secondary de-crufted project. That is software evolution and it won't change.
  
  --
  -- no sig today
43. Re:Apache Never Again by the_olo · 2012-02-22 04:47 · Score: 1
  
  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.
  
  What for? In the name of what? With such approach, when breaking feature-level backward compatibility, you'd give lots of people (not only "crazy people in Siberia") loads of pain since they would be forced to devise a strategy for getting rid of/replacing those deprecated features.
  On the other hand, the model of "old things become outdated, new things emerge, some people stick with the old and are happy, some jump onto the new stuff because it suits them better" works quite well IMHO. It's the natural way the world works. Including nature, civilization, science, technology and so on. Do you imply that there's something wrong with that and we should artificially force some change upon those who are unwilling to take it?
44. Re:Apache Never Again by Tsingi · 2012-03-01 02:18 · Score: 1
  
  I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.
  Why is this flamebait?
45. Re:Apache Never Again by Ami+Ganguli · 2012-03-05 05:55 · Score: 1
  
  CGI and FastCGI aren't the same. CGI is indeed very slow. FastCGI is pretty good.
  I vaguely remember seeing some benchmarks that claimed Nginx+FastCGI/PHP has roughly the same performance as Apache+mod_php.
  
  --
  It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Wishfull thinking by stanlyb · 2012-02-21 04:40 · Score: 0

That's all i could say.
1. Re:Wishfull thinking by Anonymous Coward · 2012-02-21 04:45 · Score: 0
  
  And you can't even spell that. How articulate you are.
2. Re:Wishfull thinking by Anonymous Coward · 2012-02-21 04:51 · Score: 0
  
  Why is it wishful thinking? Nginx isn't magic. There's no reason Apache can't get to the same level of performance.
3. Re:Wishfull thinking by cababunga · 2012-02-21 05:44 · Score: 2
  
  There, in fact, is a very good reason for that. The very fundamental architectural decision (although very common in those ancient times) of spawning one thread/process per client connection has to be changed first, before Apache can take on Nginx. That means complete rewrite; and result will not be Apache anymore.
4. Re:Wishfull thinking by Skapare · 2012-02-21 05:55 · Score: 2
  
  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).
  
  --
  now we need to go OSS in diesel cars
5. Re:Wishfull thinking by Anonymous Coward · 2012-02-21 08:34 · Score: 1
  
  For many steps along the way, yes, multiplexing things like request decode, SSL handshake/processing, etc all multiplex well. Then you hand off a given connection to a back-end application-server socket that's running as the correct user in it's own process space for the actual request to be processed once the basic stuff (cipher selection, cookie filtering, cache policies, etc) have been enacted by the multiplexed front-end.
  And once you switch to that correct user, why do you need more than one process per user for most applications, or at most one process per core per user? Again, you can multiplex things for most situations on the web. SQL databases do it, why can't the web server or business-logic/application-server do the same?
  NGinx does that multiplexed filtering/SSL/basic processing part well, and is designed around handing off the 'dynamic' part to some entire other process, which is the main reason it's so fast. It doesn't even understand the concept of having to spawn an entire other thread/process to handle a request, it's multiplexed deeply and throughly.
6. Re:Wishfull thinking by xelah · 2012-02-21 09:22 · Score: 1
  
  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.
7. Re:Wishfull thinking by Anonymous Coward · 2012-02-21 11:09 · Score: 0
  
  OTOH, Apache does process based stuff all wrong, too (they do execve() for CGI and that is where the performance dies).
  How else would you do CGI (as opposed to the various CGI alternatives, many of which Apache also supports)?
Apache by Anonymous Coward · 2012-02-21 04:43 · Score: 0, 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.
1. Re:Apache by Anonymous Coward · 2012-02-21 05:12 · Score: 0
  
  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!
2. Re:Apache by Lucky75 · 2012-02-21 05:17 · Score: 2, Funny
  
  What about easy?
  
  --
  DNA -- National Dyslexic Association
3. Re:Apache by jamiesan · 2012-02-21 05:22 · Score: 1
  
  And they can take a lot of hits and still put out?
4. Re:Apache by pr0nd3xtr · 2012-02-21 05:33 · Score: 0
  
  Yep just like Rihanna
5. Re:Apache by Anonymous Coward · 2012-02-21 05:34 · 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.
Noticeable improvement by Kohenkatz · 2012-02-21 04:46 · Score: 4, Interesting

I have been running Release Candidiates of Apache 2.4 for a few months, on an underpowered and overloaded old laptop. The performance improvements over 2.2 on that same computer are really quite noticeable.
1. Re:Noticeable improvement by Gazzonyx · 2012-02-21 07:05 · Score: 1
  
  How are you measuring that? Single client, single connection?
  
  --
  If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
2. Re:Noticeable improvement by Kohenkatz · 2012-02-21 08:11 · Score: 1
  
  I measured average response time for a range of single-client single-connection to 3 clients, 10 connections each. There were no significant changes to the setup except Apache. Yes, I know it is entirely unscientific. No, it does not represent real-world traffic for the publicly accessible server. It's still a good indicator of improvement.
Defaults still insane? by Guspaz · 2012-02-21 04:51 · Score: 4, 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.
1. Re:Defaults still insane? by bendilts · 2012-02-21 04:59 · Score: 1
  
  Insane for whom? We recently had to increase our MaxClients from 150 to 256 to 400 to 800, and we're only running on Large instances on Amazon (7.5GB of RAM). Production workloads vary widely, and I think 150 is a pretty reasonable default for many (if not most) applications.
2. Re:Defaults still insane? by PhrstBrn · 2012-02-21 05:04 · Score: 2
  
  The defaults are fine if all you do is serve up static files, which is all Apache can really do out of the box. It's when you start adding modules like mod_php that you need to start cranking MaxClients and the like down.
3. Re:Defaults still insane? by Guspaz · 2012-02-21 05:13 · Score: 2
  
  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.
4. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 05:14 · Score: 0
  
  I don't understand your comment, do you actually have a server with less than 10GB RAM? Or do you want defaults that will assume all available RAM should be dedicated to Apache. Do you consider 150 maxclients to be too high? That would only handle a fraction of our current traffic, we had to increase it by a lot and our servers handled it without a problem.
5. Re:Defaults still insane? by Guspaz · 2012-02-21 05:19 · Score: 3, 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.
6. Re:Defaults still insane? by PhrstBrn · 2012-02-21 05:22 · Score: 2
  
  How is that the responsibility of Apache? If the problem is mod_php, then the installation docs/installer for mod_php should be telling you to crank the MaxClients down.
7. Re:Defaults still insane? by silas_moeckel · 2012-02-21 05:23 · Score: 2
  
  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.
  
  --
  No sir I dont like it.
8. Re:Defaults still insane? by Guspaz · 2012-02-21 05:23 · Score: 2, 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 misconfiguring their server and throwing more RAM at the problem. They see that they're running out of RAM because Apache is sucking it all up, so they throw more RAM and concurrency at the problem. Meanwhile, for dynamic load, you probably don't want more than 8 to 12 concurrent users on a quad-core server for a typical PHP web application, since beyond that and you're just throwing RAM at the problem without improving performance.
9. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 05:30 · Score: 0
  
  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.
  where do you get 16GB ram server for hundred and some bucks? I'm serious im using some servers from Softlayer and 4GB ram upgrade costs about 150$/mo
10. Re:Defaults still insane? by Pionar · 2012-02-21 05:32 · Score: 2, 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.
11. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 05:37 · Score: 0
  
  Which requires configuration changes to add mod_php anyway. You're already in there so why not tweak that. 150 makes sense as a default.
12. Re:Defaults still insane? by LearnToSpell · 2012-02-21 05:38 · Score: 0
  
  You do realize more people run Apache on real hardware than in "your" mom's basement, right? On one setup, we have 20 servers with 64 gigs each. That's handling things nicely, but it's not overkill.
  
  --
  Haida Manga
13. Re:Defaults still insane? by Enderandrew · 2012-02-21 05:40 · Score: 1
  
  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?
  
  --
  http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
14. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 05:43 · Score: 1
  
  Ok, I get it now. You only work with a LAMP stack on a bunch of tiny servers hosting some light PHP applications. And your expectation is that Apache defaults should cater to that.
  I've been too far away from the Apache project for too long, so I guess I don't really know their direction. But some of us use it for real enterprise applications. There are other sorts of application servers we could use, but Apache works very well.
15. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 05:47 · Score: 0
  
  I run with 1800 concurrent connections in prod and the apache servers are still basically idling away under full load.
16. Re:Defaults still insane? by Guspaz · 2012-02-21 05:48 · Score: 1
  
  It's their responsibility because it's a (the?) typical deployment scenario for their software.
17. Re:Defaults still insane? by Guspaz · 2012-02-21 05:50 · Score: 2
  
  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.
18. Re:Defaults still insane? by Guspaz · 2012-02-21 05:51 · Score: 0
  
  My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".
19. Re:Defaults still insane? by PhrstBrn · 2012-02-21 05:52 · Score: 1
  
  It's the responsibility of mod_php because the typical deployment scenerio has a default that's too high.
20. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 05:53 · Score: 0
  
  Forgive me if I'm wrong, but you _appear_ to be suggesting that by tweaking, and using a lower MaxClient setting, you will be able to be able to carry on more load, presumably because each process will finish quicker? Whilst I can understand the concept behind rejecting connections before you reach swapping hell, I'm not sure I understand not wanting to set the limit as high as your memory does support, which for most dedicated servers I'd have thought was more than 150 MaxClients? Please, if you have further insight, share away. :)
21. Re:Defaults still insane? by Guspaz · 2012-02-21 05:55 · Score: 1
  
  It could; server admins might not like it, but "reduce maxclients" sounds like a better failure scenario to me than "trigger kernel OOM killer"
22. Re:Defaults still insane? by Guspaz · 2012-02-21 05:58 · Score: 1
  
  That's not entirely uncommon, no.
23. Re:Defaults still insane? by Guspaz · 2012-02-21 05:59 · Score: 1
  
  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 service. Because if your bottleneck is on your application server, why are you taking 5 seconds to process 1500 requests when you take half a second to process 150, and get the same amount of work done in the same time with far less resources?
24. Re:Defaults still insane? by Guspaz · 2012-02-21 06:01 · Score: 2
  
  Actually, you might argue also that it's the distro's fault, since they typically determine the defaults deployed applications will use.
25. Re:Defaults still insane? by Guspaz · 2012-02-21 06:04 · Score: 1
  
  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 many people throw a server with 8GB of RAM at a workload that could have been handled easily by a server with a gig of RAM, and they're paying a heck of a lot more for that 8GB server. Of course, it makes the server host happy...
26. Re:Defaults still insane? by dreemernj · 2012-02-21 06:08 · Score: 1
  
  I think configuring Apache well requires enough understanding that automating it could lead to big issues. That's just my gut reaction though. I have only configured Apache for a few different use cases. Nothing creative or even all that complex.
  
  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 do the same thing in Apache's case. Even with looking at the installed mods. I think it would end up creating more headaches than if they expected the person managing it to be able to configure it for his or her use cases.
  
  --
  1 (short ton / firkin) = 89.1432354 slugs / keg
27. Re:Defaults still insane? by mspohr · 2012-02-21 06:18 · Score: 1
  
  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.
  
  --
  I don't read your sig. Why are you reading mine?
28. Re:Defaults still insane? by DuckDodgers · 2012-02-21 06:22 · Score: 3, Insightful
  
  If you're running your own machines, maxing out the RAM makes sense. It's a one time cost and the ongoing cost to power and cool the added memory is negligible next to the rest of your budget.
  
  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.
29. Re:Defaults still insane? by Guspaz · 2012-02-21 06:28 · Score: 1
  
  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.
30. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 06:41 · Score: 0
  
  people trying to get the best they can with minimal effort.
31. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 06:52 · Score: 0
  
  Buy your own hardware.
32. Re:Defaults still insane? by mspohr · 2012-02-21 06:56 · Score: 1
  
  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."
  
  --
  I don't read your sig. Why are you reading mine?
33. Re:Defaults still insane? by Terrasque · 2012-02-21 06:59 · Score: 1
  
  if you need 1500 concurrent connections, then you REALLY should look at event driven web servers.
  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 cases cook) for every customer (and always enough standby to handle peak), and having a few waiters and cooks that instead handle multiple customers.
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
34. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 07:10 · Score: 0
  
  He's talking about the default configuration you fucking retard. The default configuration shouldn't be tailored towards the extreme minority.
  Furthermore, if bendits has MaxClients set anywhere from 400 to 800 and only has 7.5GB of RAM he's doing it horribly wrong.
35. Re:Defaults still insane? by NonUniqueNickname · 2012-02-21 07:13 · Score: 1
  
  Well said. MySQL ships with a few default config files for different scenarios, why not Apache? Apache could ship with a set of default configs (small_lamp being one of them) and save deployers a lot of frustration. A tl;dr manual for small_lamp would be a welcome addition as well. I totally understand if the good people at Apache have been too busy over the last 10 years to produce a small_lamp config. I've been too busy as well, which is why I deploy on nginx.
36. Re:Defaults still insane? by Terrasque · 2012-02-21 07:15 · Score: 1
  
  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? If a request hits the app backend then that's almost by definition cpu bound (db server is on same hardware), and allowing more requests in than spare cpu resources would just make every request go slower, use more server ram, and kill the cpu with thread switches. In addition to work up a nice request queue that will make sure the server is overworked for the forseeable future.
  And it's not the first time I've seen that attitude either. And I bet, not the last. Honestly, I don't see what use apache have now. If you serve static files, there's advantage event-driven servers. Talk to app backends, advantage event-driven. Long standing poll requests? Advantage definitely event-driven. Want to run php inside the web server? .. Okay, you got me there. But in most cases, that's not necessary. Run php as separate user, or even on a separate server. Gain security and scalability. Let web server do the web thingys, let app servers do the app thingys. Keep it clean and separated.
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
37. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 07:17 · Score: 0
  
  Interesting take. I always view Apache's defaults as set for some crippled old server that should be throw away and replaced. Seems like the first thing you always have to do is blow up/out all the limits that assume a few thousand users.
38. Re:Defaults still insane? by Desler · 2012-02-21 07:22 · Score: 1
  
  Newegg. You can buy 16GB (2x8) pairs from 150 to 190.
39. Re:Defaults still insane? by LearnToSpell · 2012-02-21 07:28 · Score: 1
  
  You really think the extreme majority is running Apache on 512M RAM? Show me some numbers, and I'll believe you.
  
  --
  Haida Manga
40. Re:Defaults still insane? by spacey · 2012-02-21 07:45 · Score: 2
  
  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.
  
  --
  == Just my opinion(s)
41. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 07:58 · Score: 0
  
  You are a fucking retard. Yes, some of you can justify the large concurrency and memory requirements. Most of the world doesn't. The bulk of Apache deployments are not what you think they are. So why should the default configuration cater to them?
42. Re:Defaults still insane? by turbidostato · 2012-02-21 08:03 · Score: 1
  
  "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).
43. Re:Defaults still insane? by 1s44c · 2012-02-21 08:17 · Score: 1
  
  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.
44. Re:Defaults still insane? by GioMac · 2012-02-21 08:33 · Score: 1
  
  I've got different experience, absolutely (see my prev message) :D
  RAM vs CPU?
  16 GB DDR3 ECC - 160 USD
  Intel Core i7-2600K - 325 USD :)
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
45. Re:Defaults still insane? by GioMac · 2012-02-21 08:38 · Score: 1
  
  I've heard tux kernel web server supports CGI. Oh! Now you can leave just 128 MB of RAM and switch to it?
  "I was running nginx on a cheap virtual server with 512M ram, That was until I moved to tux. Now running on 128 MB" :D
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
46. Re:Defaults still insane? by GioMac · 2012-02-21 08:40 · Score: 1
  
  mod_php for nginx would do the same. use mod_fcgid
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
47. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 08:58 · Score: 0
  
  Same with me, but it was 768 mb ram dedi. Switching to nginx made my blog go from 1600-1700 ms request time (local network over wifi) to 600-700. I just added varnish, and for the vast majority of the world (with cloudflare), I get under 300 ms now.
48. Re:Defaults still insane? by styrotech · 2012-02-21 09:00 · Score: 1
  
  Ok, I get it now. You only work with a LAMP stack on a bunch of tiny servers hosting some light PHP applications. And your expectation is that Apache defaults should cater to that.
  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 blogs or CMS apps won't have those tuning resources or experience available. ie these sites will (more often than not) be using the default settings.
  That is why I reckon the defaults should be oriented towards the low end servers.
49. Re:Defaults still insane? by RajivSLK · 2012-02-21 09:51 · Score: 1
  
  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.
50. Re:Defaults still insane? by kikito · 2012-02-21 09:52 · Score: 1
  
  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 $$.
51. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 10:16 · Score: 0
  
  Regardless of default settings, you're saying Apache can't handle 150 clients? LOL, nice software you got there.
  My nginx server running on a Pentium2 with 256 MB of RAM can service 1000+ simultaneous clients and 16000 connections per second. And that's through FastCGI. I'm sure it could serve considerably more static content.
52. Re:Defaults still insane? by Guspaz · 2012-02-21 10:37 · Score: 1
  
  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 handle them sequentially.
  Personally, I use Lighttpd with fastcgi. I switched from Apache to Lighttpd when nginx was still largely unknown, and while I've been impressed with nginx, I haven't seen any reason to switch, since it seems to accomplish many of the same things.
53. Re:Defaults still insane? by Guspaz · 2012-02-21 10:42 · Score: 1
  
  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.
54. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 11:01 · Score: 0
  
  > Certainly not for most LAMP installations, where 512MB of RAM is typical,
  This statement is what warranted the "mom's basement" comment, because it's laughable to have anyone who's brave enough to install Apache (through experience or as a newbie) who would have 512 MB of RAM (about what the IPhone 4 will have) and not the ubiquitous 2Gigs+. People have to question you after a statement like that, because it shows a basic failure to understand the consumer PC market, much less "the big iron" you compare it to.
  > 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.
  That's quite a tantrum.
55. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 11:23 · Score: 0
  
  if you need 1500 concurrent connections, then you REALLY should look at event driven web servers
  What, like Apache 2.4?
56. Re:Defaults still insane? by Anonymous Coward · 2012-02-21 11:31 · Score: 0
  
  I have a, perhaps stupid, question: how in the fuck do you know what the "bulk of Apache deployments" are, exactly? Do you just "know it" because of your "common sense?"
57. Re:Defaults still insane? by rev0lt · 2012-02-21 12:43 · Score: 1
  
  Some years ago I had a server with Apache 1.3 custom compiled to handle 2048 clients (the max allowed). It was a Xeon with 2GB of ram, and at some specific time periods, it would go upto 1800 processes serving active connections (I verified them, real users). The content was mostly static, with some light php served via mod_php.
  The bashing against the fork model/memory consumption is based on a fallacy - most modern operating systems implement COW, so it doesn't really matter if you have 10 or 1000 processes, because if they're not allocating data, the difference in ram usage is negligible. You waste linear address space (and some kernel memory), but no monster ram-eating.
  Dynamic content is a bit different, because it's usually a cpu-bounded process. But for most php applications (the ones I have experience with), the real showstopper is the database. Install a typical application (like Joomla) on a server with a local database and stress-test it with 200 concurrent users, and the you'll see the machine die out of MySQL starvation long before the concurrent clients are a problem. The solution? Decent hardware disk controllers with write-back cache, and dedicated database servers.
58. Re:Defaults still insane? by rev0lt · 2012-02-21 13:04 · Score: 1
  
  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(...)
  Those 150 processes will be COW'ed, so they won't use 150x the RAM of a single process. Only datapages (since code segments usually aren't writable) that differ from the parent process are actually allocated. I've had Apache 1.3 setups with 1800 processes, running fine in 2GB.
  Once I benchmarked several opensource CMS for a project, and their caching options. Using a simple almost-static cache mecanism, I got a P4 with 512Mb handling up to 5000 simultaneous connections, before the machine started dying of resource starvation.
59. Re:Defaults still insane? by silas_moeckel · 2012-02-21 16:01 · Score: 1
  
  Not a bottleneck issue, my point is apache can easily handle a lot more than it's quite modest defaults and that it's not so unusual. I do a lot of work inside the hosting business throw 10 or 20k web sites on a server cluster, coupled with end users badly written code, idiotic javascript etc etc etc and you can quickly get a few k simultaneous connections mostly doing nothing. Cheap 3k a pop servers handle this quite well (with off box storage). If our average response time was even 500ms we would have piles of angry clients, mid 100's is our average and we seem to be better then our competition.
  
  --
  No sir I dont like it.
60. Re:Defaults still insane? by mug+funky · 2012-02-21 17:12 · Score: 1
  
  10 gigs of RAM? maybe that was insane in 1999...
61. Re:Defaults still insane? by anomaly256 · 2012-02-21 18:06 · Score: 1
  
  Agreed. My currently-old laptop has 8.. and my next one is due to have 24 or more and I get that in 3 months time.
62. Re:Defaults still insane? by jersey_emt · 2012-02-21 19:55 · Score: 1
  
  There are many, many sites (and therefore many, many servers) that have outgrown what shared hosting can handle but where a dedicated server would be excessively overkill (and not affordable from the sites' revenues). These are hosted on VPS accounts, most with under 1 GB of RAM. Even with a simple site, Apache would start thrashing to hell long before 150 clients connected at the same time with 512 MB - 1 GB of RAM. The sites running on dedicated servers with gobs of RAM are greatly outnumbered by sites running on a low-end VPS. So yes, 150 maxclients is far too high as a default value.
  
  --
  My spoon is too big.
63. Re:Defaults still insane? by jersey_emt · 2012-02-21 19:58 · Score: 1
  
  Because there are a lot more VPS's with (comparatively) low memory than dedicated servers. Default configs should cater to the masses, not the minority.
  
  --
  My spoon is too big.
64. Re:Defaults still insane? by Terrasque · 2012-02-21 21:02 · Score: 1
  
  That's what I get for not reading the release notes.. But still, the new event mod seems to be a bit limited.
  
  The event Multi-Processing Module (MPM) is designed to allow more requests to be served simultaneously by passing off some processing work to supporting threads, freeing up the main threads to work on new requests. It is based on the worker MPM, which implements a hybrid multi-process multi-threaded server.
  This MPM tries to fix the 'keep alive problem' in HTTP. After a client completes the first request, the client can keep the connection open, and send further requests using the same socket. This can save signifigant overhead in creating TCP connections. However, Apache HTTP Server traditionally keeps an entire child process/thread waiting for data from the client, which brings its own disadvantages. To solve this problem, this MPM uses a dedicated thread to handle both the Listening sockets, all sockets that are in a Keep Alive state, and sockets where the handler and protocol filters have done their work and the only remaining thing to do is send the data to the client. The status page of mod_status shows how many connections are in the mentioned states.
  The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection.
  So it looks like it still got some ways to go, before being on the same level as for example nginx. It seems like a wrapper around the worker thread, and can keep track of idle connections. However, on nginx or cherokee, which are those I have most experience with, it can also keeps connections idle while waiting for new data from backend / storage. It seems like that event module still needs a thread for that. Will be interesting to see practical comparisons :)
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
65. Re:Defaults still insane? by DuckDodgers · 2012-02-22 02:58 · Score: 1
  
  Again, if you're buying your own hardware then maxing the RAM is important. I'm strictly speaking of renting cloud servers from hosting companies - added RAM for your virtual servers gets expensive fast.
66. Re:Defaults still insane? by Guspaz · 2012-02-22 03:41 · Score: 1
  
  What you find in a desktop computer or laptop is not the same as what you find in a mass-market dedicated server or VPS.
67. Re:Defaults still insane? by Guspaz · 2012-02-22 03:48 · Score: 1
  
  This statement is what warranted the "mom's basement" comment, because it's laughable to have anyone who's brave enough to install Apache (through experience or as a newbie) who would have 512 MB of RAM (about what the IPhone 4 will have) and not the ubiquitous 2Gigs+. People have to question you after a statement like that, because it shows a basic failure to understand the consumer PC market, much less "the big iron" you compare it to.
  Where did I ever say anything about the amount of RAM in the consumer PC market? 512MB is a typical size for many VPS providers, and for those who offer that size as their entry-level offering, it's normally their most popular service level by a huge margin because it's good enough for a significant amount of load if properly tweaked. Dedicated servers now tend to feature more RAM than this, but 10GB+ is rare; only a handful of SoftLayer's offerings come with that much RAM, and they're some of their most expensive packages. 2GB+ is pretty ubiquitous for dedicated servers these days (1GB is not uncommon), but that's not the case for the virtual hosting market, which tends to have far higher density.
  I don't know why you're bringing smartphones into this; apparently you think a VPS provider runs their infrastructure on iPhones?
68. Re:Defaults still insane? by anomaly256 · 2012-02-22 09:32 · Score: 1
  
  True. But the original argument that apache is by default tuned to require 10gb is still squarely false, and the premise that 10gb is an unreasonable expectation is still absurd. Plus there's the whole 'if you can't/don't want to tune it properly then it's not for you in the first place' thing as well. Who goes out and buys an 18 wheel Mack truck then complains when it doesn't fit in their suburban driveway? Horses for courses and all that..
69. Re:Defaults still insane? by Guspaz · 2012-02-22 11:13 · Score: 1
  
  Who goes out and buys an 18 wheel Mack truck then complains when it doesn't fit in their suburban driveway? Horses for courses and all that..
  Far too many people, it seems. In most cases, the problem is solved by throwing more RAM at the problem, rather than properly configuring Apache to work (well!) within the available RAM.
A bit bitter are we? by PhrostyMcByte · 2012-02-21 04:53 · Score: 4, 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.
1. Re:A bit bitter are we? by bigbangnet · 2012-02-21 05:03 · Score: 1
  
  I made some search on nginx vs apache 2.4 and no test as been done so when he says " who may be "better" " so I think its right to say this with quotes. After those tests are done then we could probably judge it but not before.
2. Re:A bit bitter are we? by phantomfive · 2012-02-21 05:29 · Score: 2
  
  They probably feel like Nginx got its reputation as fast from tests and benchmarks that aren't relevant in the real world. That kind of thing does happen a lot in the benchmarking world, but coming up with something better can be hard. Notice also his emphasis on 'true performance' and 'real world performance.'
  
  --
  "First they came for the slanderers and i said nothing."
3. Re:A bit bitter are we? by Anonymous Coward · 2012-02-21 05:37 · Score: 0
  
  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%.
  Don't get me wrong Apache is quite good for serving some types of files, but its the extra cruft that makes Apache a nightmare. on a site with a few thousand requests per seconds Apache just cannot cope with the amount of requests without constantly forking processes to the point where 99% of the CPU is utilized. no amount of configuration tweaks or recoding of my apps can fix this.
  Eventually I gave up and switched to nginx / php-fpm. I was able to drop some of my production boxes from 9.0~ load to 3.4~. it's great that Apache are realizing that their software is just really second rate in comparison to other products on the market and I welcome any improvements. perhaps some day it may actually be worth changing php-fpm back to Apache to retain those seamless rewrite rules they have.
  however, there is no way in hell that I will be getting rid of nginx, it uses almost no CPU at all to serve static files and that is something I am fairly certain Apache will never be able to accomplish on its own.
4. Re:A bit bitter are we? by VGPowerlord · 2012-02-21 06:02 · Score: 2
  
  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, but don't let pesky things like facts stop you.
  
  --
  GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
5. Re:A bit bitter are we? by aztracker1 · 2012-02-21 07:34 · Score: 1
  
  Well, for that matter, IIS is a very strong performer in "real world" tests... I'm still keeping an eye on NodeJS and MongoDB even if my day job mostly requires C# (ASP.Net/MVC) and MS-SQL.
  
  --
  Michael J. Ryan - tracker1.info
6. Re:A bit bitter are we? by flimflammer · 2012-02-21 08:06 · Score: 1
  
  Why would 2.2 getting destroyed matter when 2.4.1 is the current prod version?
7. Re:A bit bitter are we? by Colin+Smith · 2012-02-21 10:47 · Score: 1
  
  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.
  
  --
  Deleted
8. Re:A bit bitter are we? by anomaly256 · 2012-02-21 18:07 · Score: 1
  
  "Bitter?"
  "Yup. Bit him too."
Less PR, more innovation by Anonymous Coward · 2012-02-21 05:03 · Score: 0

The truth is, nginx IS lightningly fast. It has its place, just like Apache.
But dear Apache foundation, please spend your money in making the things instead of making people believe you make things.
What we need by Anonymous Coward · 2012-02-21 05:11 · 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.
1. Re:What we need by Anonymous Coward · 2012-02-21 05:58 · Score: 0
  
  Cherokee ...
2. Re:What we need by OverlordQ · 2012-02-21 05:59 · Score: 1
  
  In case some people don't know, nginx uses http1 to connect to the servers, which means a new connection for reach request.
  HTTP/1.1 proxying is currently available in the development version so if needed you can use that.
  
  --
  Your hair look like poop, Bob! - Wanker.
3. Re:What we need by Anonymous Coward · 2012-02-21 06:00 · Score: 0
  
  Lighttpd will do the job nicely, especially on php-cgi support.
4. Re:What we need by K.+S.+Kyosuke · 2012-02-21 06:28 · Score: 1
  
  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.
  
  --
  Ezekiel 23:20
5. Re:What we need by Jonner · 2012-02-21 07:36 · Score: 1
  
  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.
6. Re:What we need by Anonymous Coward · 2012-02-21 08:42 · Score: 0
  
  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.
7. Re:What we need by glennpratt · 2012-02-21 08:48 · Score: 1
  
  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
  "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."
8. Re:What we need by Per+Wigren · 2012-02-21 09:09 · Score: 1
  
  ... marching on the trail of tears.
  
  --
  My other account has a 3-digit UID.
9. Re:What we need by adamgundy · 2012-02-21 10:03 · Score: 1
  
  the major reason none of the web servers support multiplexed fastcgi is that none of the fastcgi servers support it (ie PHP etc).
  that said, there is a third party module for nginx to provide multiplexed fastcgi.. ie comes with demo fastcgi servers to test with.
  https://github.com/rsms/afcgi
10. Re:What we need by Jonner · 2012-02-21 10:44 · Score: 1
  
  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.
11. Re:What we need by Jonner · 2012-02-21 10:55 · Score: 1
  
  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
  "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 comment when you can just Google something simple like this?
12. Re:What we need by Anonymous Coward · 2012-02-21 10:58 · Score: 0
  
  I'm assuming that $30mil donated to nginx will help get proper connection pooling and multiplexing finally implemented. Nice to know about the devel info. Thanks :-)
13. Re:What we need by Thundersnatch · 2012-02-21 11:07 · Score: 1
  
  Nginx 1.0+ supports backend keepalives with a patch and module, but they are still not in official release. But this code comes from the principal nginx author, so it will make it into release soon.
  That said, your back-ends are usually very close network-wise to nginx proxies, and connections can be established and torn down in less than 1 ms. Since the back-ends are usually thread-based, this is a good idea anyway (which is why everybody has to turn off HTTP keepalives in Apache when they start to scale). Disabling HTTP keepalives SUCKS for the client's experience, especially if they are on wireless/mobile connections or on another continent.
  I manage a medium-sized SaaS application with about 0.7M users, and we front dozens of honking physical JBoss/Tomcat boxes with a single-core linux VM running nginx with 1 GB of RAM (with a hot standby of course). Nginx is only proxying to back-ends, not serving static files (except for a small 512MB set of really hot files using proxy_cache which stays in the filesystem cache). Nginx itself uses only about 100 MB with 8 worker processes. This isn't surprising: even the biggest $50K F5 load balancers have very wimpy specifications for CPU and RAM, but like nginx they use an event-driven model to keep RAM usage and context-switching to a minimum.
  One problem running nginx on Linux is that asynchronous IO on Linux is horribly broken by design, and only works for databases that use direct uncached IO. So we are looking at moving nginx to FreeBSD so we can take advantage of asynchronous disk IO as well as the default asynchronous network IO.
  The one-thread/process-per-connection model of Apache really just doesn't cut it for web-scale workloads. We were able to re-purpose our dedicated Apache front-end boxes as application servers instead because of the RAM savings. So nginx saves us about $2k per month in colo costs.
14. Re:What we need by glennpratt · 2012-02-21 16:14 · Score: 1
  
  Sorry, that was dumb and rude on my part - I glossed over everything but multiplexing.
  Your right, Nginx doesn't have a FastCGI process manager built in. PHP has a couple, I use PHP-FPM which is part of PHP as of 5.3.3. There's also spawn-fcgi ( http://redmine.lighttpd.net/projects/spawn-fcgi/wiki ) for more generic needs. This completely seperates the HTTP server from the application (even to another machine if you like), but is certainly another thing to configure.
  As for actual connection persistence to backends, I know that has been discussed, but thought the performance difference was negligible and added serious complexity to have Nginx maintain a connection pool to backends.
So?? by Anonymous Coward · 2012-02-21 05:38 · Score: 0

The number one webserver is now going after the #2 webserver.
Interesting trend.
Fixes I'd rather have by Skapare · 2012-02-21 05:46 · Score: 3, Interesting

I'd rather have better control features, such as completely redoing the vhost matching method.

--
now we need to go OSS in diesel cars
1. Re:Fixes I'd rather have by hobarrera · 2012-02-21 13:23 · Score: 1
  
  Yes, that's right, mixed matching between hosts and IPs seems to be imposible in httpd.
Here's how to computer the MaxClients value by Anonymous Coward · 2012-02-21 06:02 · Score: 1

Looks like there's much hand-wringing all over the net about what the MaxClients should be but the only place I've seen someone actually propose a method for computing it for a given load (in terms of throughput and service time) is here . Nice to see someone actually rolling up there sleeves and actually applying some theory to the problem.
Ubuntu vs Gentoo by inhuman_4 · 2012-02-21 06:09 · 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.
1. Re:Ubuntu vs Gentoo by Anonymous Coward · 2012-02-21 06:49 · Score: 1
  
  I completely disagree. I replace Apache with Nginx in crazy complex enterprise environments regularly. Apache has more fringe features, but there are almost always alternatives.
2. Re:Ubuntu vs Gentoo by Terrasque · 2012-02-21 07:21 · Score: 1
  
  Apache is the Slackware/Gentoo of the web server world.
  That's probably very true. Thanks for pointing that out :)
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
3. Re:Ubuntu vs Gentoo by GioMac · 2012-02-21 07:29 · Score: 1
  
  And how enterprises deal with protocol filtering/security then? :)
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
4. Re:Ubuntu vs Gentoo by hedleyroos · 2012-02-21 09:37 · Score: 1
  
  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.
5. Re:Ubuntu vs Gentoo by hobarrera · 2012-02-21 13:25 · Score: 1
  
  Some very huge websites with millones of visits a day (even hour) run nginx. Apache seems to be far more newbie-oriented in a way; since a great deal of web apps (php anyone?) have very detailed instructions on how to make them run with apache, but not with any other server.
6. Re:Ubuntu vs Gentoo by Anonymous Coward · 2012-02-22 05:52 · Score: 0
  
  I'm curious what your definition of "protocol filtering and security" is, though I suspect you're just a troll. Apache is no more of a firewall than nginx is. If you want a firewall, get a damn firewall.
Performance? RAM usage? by GioMac · 2012-02-21 06:16 · 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-cgi (189)
Private + Shared = RAM used Program
This is what I've got with > 250 req/sec @1.6GHz dual cores, 8GB RAM. what more can nginx give and for what?
Average: all 2.35 0.00 2.08 3.24 0.00 92.33
If you are running it as a balancer - you're wrong! Take LVS.
If you are running it as a filter - you're wrong! Take mod_security or appliances (most of them are based on httpd+mod_security+mod_proxy) - nginx can't do this.
For anything else - it doesn't matter - you're wrong, again.
1 GB RAM vs delay + reading books, code and googling.
Maybe default manner of apache configurations and default MPM's are too heavy for you with default modules and features?
If you are running it for performance and response delays - Yes, it will be slower than nginx with single dumb empty virtual host with 0 add ons. You just CAN'T do analysis of traffic, filtering without buffering it. So, good servers will always have delays. It's OK for internet, not critical. Using it not for internet? For backend? Then OK.
I'm happy with 2.2 too.
Yes, I do like some nginx tricks and I wish it to be in apache too, but I'll never say that apache cannot handle something or do something or eat more RAM. It depends how do you configure it with your CPU and RAM resources, optimize.

--
"It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
1. Re:Performance? RAM usage? by kervin · 2012-02-21 06:26 · Score: 1
  
  I'm curious, what MPM are you using? Event MPM?
2. Re:Performance? RAM usage? by GioMac · 2012-02-21 06:36 · Score: 1
  
  Worker. Event - not yet.
  I was unhappy with worker MPM three years before, because of constant crashes, I didn't investigate the reason, but now it's working very fine for me.
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
3. Re:Performance? RAM usage? by Terrasque · 2012-02-21 07:34 · Score: 1
  
  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?
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
4. Re:Performance? RAM usage? by GioMac · 2012-02-21 07:49 · Score: 1
  
  I can't say that it's idle, some virtual hosts are running over 30 processes sometimes. Static files ar served by apache, content is processed through reverse squid 2.2 for http 1.1 - very small part is cached (assume none), data cannot be cached with memcached because it's shared hosting running for different needs. DB is on different machine, some part goes through mysql-proxy, web server nodes are running behind L3 Balancer with persistency per IP, L2/L3/TCP filtering done with iptables and automated scripts for checking connection states on both LVS-NAT and realservers, L7 filtering with additional custom mod_security rules, processes running with mod_fcgid, selinux in effect, files are shared with gluster. You can notice some iowait numbers too because of storage HW problems.
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  28086 vu2150 20 0 528m 35m 19m S 8.9 0.4 0:01.23 php-cgi
  27671 vu2176 20 0 542m 52m 23m S 2.7 0.7 0:02.70 php-cgi
  32005 squid 20 0 169m 104m 5264 S 2.0 1.3 19:24.22 squid
  7828 root 20 0 194m 74m 1040 S 1.7 0.9 626:35.09 glusterfs
  28080 vu2240 20 0 626m 20m 8916 S 0.7 0.3 0:03.93 php-cgi
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
5. Re:Performance? RAM usage? by Terrasque · 2012-02-21 08:14 · Score: 1
  
  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.. For that not to be CPU bound, wouldn't that mean that each php process on average need to spend around 90% or more IO bound?
  Please don't get me wrong here, I'm not trying to point out wrong things here. I'm just fascinated by large-scale web systems, and honestly curious about the different challenges between the level I'm used to (have yet have any need to move something to more than 3 servers, and rather small servers too. Most stuff I poke a finger into works fine on one machine with some consideration. Oh, and usually working on 1-2 web apps per system), and large scale systems.
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
6. Re:Performance? RAM usage? by GioMac · 2012-02-21 08:28 · Score: 1
  
  Honestly, I'm also surprised :D
  Probably the reason could be what processes are doing to load CPU's, processes are already in the memory and CPU doesn't have to start them.
  My friend is running large hosts with less security and what I saw at shared hosting providers - they had muuuch higher CPU load and because of this only, but less RAM. I prefer to buy RAM. More vhosts you serve - more RAM you need, but less CPU (per host), from point of view of investment it's better to buy RAM - its cheap and no need to buy larger system, at least you have power economy, not talking about the delays for starting processes.
  Maybe today there is nothing special to process (_compute_) with PHP.
  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
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
7. Re:Performance? RAM usage? by shish · 2012-02-21 08:42 · Score: 1
  
  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, stick with what you know; but I found nginx only took a couple of days to grok, and now that I know both, nginx is faster and easier to administer
  
  --
  I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
8. Re:Performance? RAM usage? by Terrasque · 2012-02-21 09:13 · Score: 1
  
  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 (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, but SSD is quite a bit larger compared to price, and still vastly superior to HDD. Ram first cache, ssd 2nd cache, disk for the stuff that no one use.
  And regarding the game you mentioned.. My experience is that in the vast majority of cases, the speed problem isn't the language, but stupid code.. Write smarter, not harder! :D I don't know what he did wrong, but I know that he did something (or many things) very wrongly. 12 cores? For 400 users?
  Reminds me of one of my sites, where you have long polling. First implentation (which I knew was bad, but it was easy and worked for small amounts of users) was just apache -> mod_python -> django -> polling events table every 1 second to see if latest id was changed. And abort routine after 60 seconds and reconnect.
  As I said, it worked... For small amounts of users. When it started to hit the limit it hit it in a spectacular fashion. As requests got delayed, and errors started cropping up, connect queues piled up and clients reconnected and reconnected... It was like a small snowflake starting to roll downhill, and suddenly a house-sized snowball hit our server.
  The current rewrite works fine for up to 1000 concurrent requests (tested on my dev server, which is weaker than prod), and worked (albeit with noticeable delays) up to 1500 connections. Current peak is around 500 connections. If we hit the new limit I'll need to rewrite it again. I have some ideas, but it would require more complexity overall, so for now the current one works great.
  Err, anyway my point with that rambling was.. If you do something very stupid, then you need gigantic amounts of hardware, and can probably do things smarter. Of course..You have to look at the situation :)
  
  --
  It's The Golden Rule: "He who has the gold makes the rules."
9. Re:Performance? RAM usage? by JonySuede · 2012-02-21 11:00 · Score: 1
  
  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...
  
  --
  Jehovah be praised, Oracle was not selected
10. Re:Performance? RAM usage? by rev0lt · 2012-02-21 13:28 · Score: 1
  
  Most modern schedulers will detect "idle processes" and adjust accordingly. Usually programs don't get an equal timeslice, but a fair one. Also, it seems everyone talks about memory but forgets that most modern operating systems use COW (http://en.wikipedia.org/wiki/Copy-on-write), so only the data is actually allocated in memory between forked processes.
  In my (somewhat limited) experience, PHP parsing/executing isn't usually the bottleneck (except for crazy apps like Magento), the database is.
11. Re:Performance? RAM usage? by GioMac · 2012-02-21 19:28 · Score: 1
  
  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)
  Great, that's the place where you must use nginx, exactly. But we know that you'll not gonna run 1500 hit/sec site on this VM, I think so :)
  Rough comparison:
  16.4 MiB + 1.2 MiB = 17.6 MiB nginx (9)
  vs
  202.6 MiB + 50.1 MiB = 252.7 MiB httpd (190)
  per process comparison (we assume httpd with same or even less number of processes can handle same number of requests):
  17.6/9 = 1.95 MiB - nginx
  252.7/190 = 1.33 MiB - httpd
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
12. Re:Performance? RAM usage? by GioMac · 2012-02-21 19:33 · Score: 1
  
  Thanks for sharing :)
  For HE/Enterprise there are SSD caching and dynamic allocation of storage already available - ex. EMC FAST and FAST Cache.
  From low-priced solutions - Adaptec MaxIQ.
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
13. Re:Performance? RAM usage? by GioMac · 2012-02-21 19:38 · Score: 1
  
  Nope, they were using mysql for history and current states - switched to disk storage, using MEMORY DB for current states, there is no iowait, only CPU usage by the C++ processes.
  Main reason of load: code (?).
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
MOD_PHP any memory changes by Anonymous Coward · 2012-02-21 06:20 · Score: 0

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.
1. Re:MOD_PHP any memory changes by GioMac · 2012-02-21 06:31 · Score: 1
  
  mod_php is not a part of apache project - they can't do any changes there.
  RAM usage will depend on how many apache processes are run, because every process will preload PHP module, which is quite large.
  - More RAM (mostly)
  - Less security (processes are not separated by default, unless you are running every apache process with different users somehow)
  - Stability - module died, apache died or skipped every 1/x connections (depending on MPM)
  - Debug - harder to know where is the problem - in apache or PHP
  Try to switch to backend-frontent architecture, for ex, use mod_fcgid, php-fpm.
  + dynamic or static child spawning depending on parameters/hosts/ip's etc you want
  + separate hosts, processes
  + security
  + flexibility for php.ini
  + stability
  - Little less RAM
  etc
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
2. Re:MOD_PHP any memory changes by GioMac · 2012-02-21 06:38 · Score: 1
  
  * I mean php module will eat RAM, module itself is small.
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
3. Re:MOD_PHP any memory changes by TheNinjaroach · 2012-02-21 06:57 · Score: 1
  
  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.
  
  --
  I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
4. Re:MOD_PHP any memory changes by rev0lt · 2012-02-21 13:36 · Score: 1
  
  - Less security (processes are not separated by default, unless you are running every apache process with different users somehow)
  I use mpm_itk to solve this problem in small deployments. It's based on prefork, so you can specify pools of processes with different uid/gid to be used on vhosts.
  
  One of the big problems with mod_php is that not every extension is thread-safe (gettext comes to mind), so you should use prefork anyway for generic installations, so a fcgi setup will be far more flexible.
5. Re:MOD_PHP any memory changes by Anonymous Coward · 2012-02-21 17:13 · Score: 0
  
  Sample output of top - each client connection sends XML data to the web server to process and store on a backend MySQL:
  top - 23:54:08 up 400 days, 8:37, 1 user, load average: 0.94, 1.13, 1.17
  Tasks: 121 total, 2 running, 118 sleeping, 0 stopped, 1 zombie
  Cpu(s): 19.5%us, 0.5%sy, 0.0%ni, 79.3%id, 0.0%wa, 0.3%hi, 0.4%si, 0.0%st
  Mem: 8199216k total, 7640012k used, 559204k free, 321264k buffers
  Swap: 2097144k total, 708k used, 2096436k free, 6807428k cached
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  18622 www-data 20 0 182m 16m 4952 S 7 0.2 0:06.18 apache2
  18709 www-data 20 0 182m 15m 4948 S 6 0.2 0:16.16 apache2
  19179 www-data 20 0 182m 16m 4728 S 6 0.2 0:03.80 apache2
  19288 www-data 20 0 176m 6580 1796 S 5 0.1 0:00.84 apache2
  19292 www-data 20 0 180m 13m 4344 S 5 0.2 0:00.72 apache2
  19310 www-data 20 0 176m 6576 1792 S 5 0.1 0:00.30 apache2
  18957 www-data 20 0 182m 15m 4836 S 5 0.2 0:09.62 apache2
  19121 www-data 20 0 180m 14m 4956 S 5 0.2 0:05.66 apache2
  19191 www-data 20 0 180m 14m 4952 S 5 0.2 0:04.62 apache2
  18363 www-data 20 0 182m 16m 4864 S 4 0.2 0:10.86 apache2
  18745 www-data 20 0 180m 14m 4956 S 4 0.2 0:14.14 apache2
  19040 www-data 20 0 180m 14m 4860 S 4 0.2 0:07.84 apache2
  19132 www-data 20 0 195m 28m 4916 S 4 0.4 0:10.06 apache2
  19197 www-data 20 0 180m 14m 4828 S 4 0.2 0:03.12 apache2
  19302 www-data 20 0 176m 6576 1792 S 4 0.1 0:00.34 apache2
  19317 www-data 20 0 185m 18m 4656 R 3 0.2 0:00.10 apache2
  19284 www-data 20 0 182m 16m 4572 S 3 0.2 0:01.00 apache2
6. Re:MOD_PHP any memory changes by GioMac · 2012-02-21 19:47 · Score: 1
  
  One of the big problems with mod_php is that not every extension is thread-safe (gettext comes to mind), so you should use prefork anyway for generic installations, so a fcgi setup will be far more flexible.
  You're absolutely right, I had the same situation and switching to CGI solved all the problems.
  
  --
  "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
The only reason to use Apache is for AJP by Anonymous Coward · 2012-02-21 06:35 · Score: 0

Nginx has an AJP module, but it is third party.
Re:Here's how to computer the MaxClients value by Anonymous Coward · 2012-02-21 06:56 · Score: 0

That seems like link spam to me. Lots of useless posts with little substance.

Throughput and service time has little to do with MaxClients, other than if you set MaxClients too high your server will swap to death or run out of memory in high concurrency situations- and then throughput and service time drop rock bottom.

Figuring out MaxClients isn't that difficult. Set MaxClients to something high first, then use ab2 (apachebench) or similar to do X concurrent requests of your most bloated page (serving static pages won't use much memory, it's stuff like php and modperl that use more memory).

Now increase X till apache (and other associated stuff[1]) is using the maximum memory[2] you want on that server. X is now the upperbound of what your MaxClients value should be. You may wish to set MaxClients lower than that as a safety measure, in case a popular web page one day uses more memory, or your other services on that server use more memory.

Now your server won't fall over. There's nothing you can do to make a small server handle 1 million requests within 1 second, but the correct MaxClients setting means your server won't fall over when that happens (unless you have crap hardware or drivers).

[1] Your apache webapp might be using other services/servers on that server and that stuff might also use more memory as the concurrent connections increase.

[2] Calculating memory usage can be a bit tricky, but you can count shared memory in an apache process once, the rest is nonshared.
The sure way is to increase concurrency till it swaps, to detect whether the server is starting to "swap" you can use the "page out" statistics (you can get it for Linux and Windows). If you have lots of page-outs the server is "swapping".
All that and the configuration by Gazzonyx · 2012-02-21 07:03 · Score: 1

My biggest problem with Apache is configuring it. The configuration file is simply a mess. You have overrides that can be included from other files, etc. Even using Webmin doesn't make the configuration that much easier.

--
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Node.js Is Bad Ass Rock Star Tech by Temujin_12 · 2012-02-21 07:46 · Score: 1

What's missing in this debate is the fact that Node.js Is Bad Ass Rock Star Tech.

--
Faith is a willingness to accept something w/o complete proof and to act on it. Reason allows you to correct that faith.
1. Re:Node.js Is Bad Ass Rock Star Tech by Anonymous Coward · 2012-02-21 09:00 · Score: 0
  
  What's missing in this debate is the fact that Node.js Is Bad Ass Rock Star Tech.
  brilliant!
2. Re:Node.js Is Bad Ass Rock Star Tech by Dr.Dubious+DDQ · 2012-02-21 11:12 · Score: 1
  
  Kind of off-topic, but I've been wondering if it'd be reasonably easy to set up node.js as a fastcgi provider for cherokee or nginx to send server-side javascript to for processing. That'd give me a simple way to try simple little server-side javascript for learning.
  
  --
  Hacker Public Radio is our Friend
3. Re:Node.js Is Bad Ass Rock Star Tech by mr_stinky_britches · 2012-02-21 13:47 · Score: 1
  
  awesome vid, sums up the state of web development today!
  
  --
  Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
AuthLDAPUrl Directive syntax still needs fixed. by Medievalist · 2012-02-21 08:32 · Score: 1

Congratulations, you posted in this thread without calling some other poster names! Oh, wait, you're first post. D'Oh!
I just wish they'd fix the syntax for the AuthLDAPUrl Directive so that you could specify unencrypted binds on a local socket and failover to encrypted binds over the network. It's the basic use case for well-structured large networks, which will have a local LDAP slave for speed and a central node somewhere else on the LAN.
I do love apache, though, warts and all. Great software.
Apache is the swiss army knife of web servers by Colin+Smith · 2012-02-21 10:31 · Score: 1

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.

--
Deleted
G-WAN Is faster.. by JohnnyOpcode · 2012-02-21 10:55 · Score: 0

The new kid on the block is way faster.. G-WAN has more bang for zero bucks.. Don't believe me..go benchmark the latest build against nginx or apache.. johnny!!!
1. Re:G-WAN Is faster.. by mr_stinky_britches · 2012-02-21 13:51 · Score: 1
  
  Too bad it's not open-source: http://gwan.com/download
  Linux binaries? That is so 2001.
  
  --
  Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
2. Re:G-WAN Is faster.. by JohnnyOpcode · 2012-02-21 14:09 · Score: 0
  
  It's free as in beer..
  
  Open-source is so yesterday and so corporately tainted..
  
  johnny
  
  p.s. being a fanboy ain't cool anymore..being unique will get you the chics these days (in your case it will be an inflatable one).
Configuration by hobarrera · 2012-02-21 13:21 · Score: 1

I didn't switch to lighttpd, and then nginx just because of performance.
It was, in part, because of configuration. As some Anonymous Coward trolled earlier on, the configuration syntax is pretty pretty complicated, and there are some multisite configurations which are imposible to achieve. It's really a mess, and not-too-well documented.
I have very few servers, each with several sites, with TLS and SNI, and some need to be redirected to others, some are matched with a regex to get some resources from one place, and other resources from some other application on a socket.
This took a few hours the first time with nginx, a few days with lighttpd, but I could *never* achieve this with apache's httpd!
Nginx? What about yaws? by Anonymous Coward · 2012-02-22 00:18 · Score: 0

Yaws is a webserver written in Erlang that does 80,000 concurrent connections.
Apache and Nginx only see the dust trail...
MOD UP EVEN MORE ^^^ by thaig · 2012-02-22 02:01 · Score: 1

I wish I could mod the Kitchen Sink comment up more as it hits the nail on the head. Another example is when someone used to say, "I'm going to make a small fast text editor not like those bloated things," and you could cue forward a few years to the editor which changes description from "fast and light," to , "full featured." It seems to be natural to pretend that there aren't tradeoffs.

--
This is all just my personal opinion.
Apache MPM Worker + FastCGI with fcgid by kbahey · 2012-02-23 04:03 · Score: 2

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, Inc: Drupal, WordPress, and LAMP performance tuning.