Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apache 2.4 Takes Direct Aim At Nginx

timothy posted more than 2 years ago | from the competition-drives-progress dept.

The Internet 209

darthcamaro writes "The world's most popular web server is out with a major new release today that has one key goal — deliver more performance than ever before. Improved caching, proxy modules as well as new session control are also key highlights of the release. 'We also show that as far as true performance is based — real-world performance as seen by the end-user- 2.4 is as fast, and even faster than some of the servers who may be "better" known as being "fast", like nginx,' Jim Jagielski, ASF President and Apache HTTP Server Project Management Committee, told InternetNews.com." Here's list of new features in 2.4.

cancel ×

209 comments

Sorry! There are no comments related to the filter you selected.

First post (-1)

Anonymous Coward | more than 2 years ago | (#39112251)

First!

Re:First post (5, Funny)

Anonymous Coward | more than 2 years ago | (#39112721)

You must be nginx with such a fast response.

improve the noob XML style config (-1)

Anonymous Coward | more than 2 years ago | (#39112267)

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 (-1, Flamebait)

Anonymous Coward | more than 2 years ago | (#39112287)

I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.

Re:Apache Never Again (4, Insightful)

TheCRAIGGERS (909877) | more than 2 years ago | (#39112369)

So, your claim is that software can never improve?

Re:Apache Never Again (1)

Skapare (16644) | more than 2 years ago | (#39113407)

Anonymous Coward switching to NginX would prove software can improve. The question is, does it need to be done by rethinking and starting over from scratch.

Re:Apache Never Again (5, Insightful)

Simon Brooke (45012) | more than 2 years ago | (#39112415)

I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.

Quick translation into English: 'I am too clueless to run a webserver, but wish to get First Post'.

Re:Apache Never Again (2, Insightful)

0100010001010011 (652467) | more than 2 years ago | (#39112791)

Quick translation into English: "I like my sendmail-esque configuration just fine. It's job security."

Re:Apache Never Again (1)

Anonymous Coward | more than 2 years ago | (#39113315)

What, precisely, is "sendmail-esque" about the Apache configuration? If you're writing your httpd.conf in m4, you're doing it wrong.

Re:Apache Never Again (1)

archen (447353) | more than 2 years ago | (#39113877)

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.

Re:Apache Never Again (2, Insightful)

Anonymous Coward | more than 2 years ago | (#39114253)

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.

Re:Apache Never Again (1)

Anonymous Coward | more than 2 years ago | (#39113441)

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.

Re:Apache Never Again (1)

sribe (304414) | more than 2 years ago | (#39112463)

I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.

Care to elaborate? I'm faced with that decision right now.

Re:Apache Never Again (1, Informative)

roman_mir (125474) | more than 2 years ago | (#39112779)

I use Apache Server with mod_jk.so to redirect requests to Tomcat and mod_ssl so that Apache Server is responsible for channel encryption. If you have to do something like that your best bet is Apache Server, not Nginx.

Re:Apache Never Again (1)

pak9rabid (1011935) | more than 2 years ago | (#39113275)

What a stupid thing to say. Nginx can do both of these tasks (SSL endpoint, reverse-proxy) well...probably even faster.

Re:Apache Never Again (1)

hlavac (914630) | more than 2 years ago | (#39113555)

Isn't mod_jk obsolete?? I thouht you are supposed to use mod_proxy_ajp, especially behind SSL...

Re:Apache Never Again (1)

Anonymous Coward | more than 2 years ago | (#39114209)

It doesn't support jk/ajp, but HTTP is supported.

Re:Apache Never Again (1, Insightful)

roman_mir (125474) | more than 2 years ago | (#39114337)

No, nginx is slower when talking to Apache Tomcat than Apache server is, check your mouth at the door.

Re:Apache Never Again (5, Interesting)

OliWarner (1529079) | more than 2 years ago | (#39112957)

I think this is a fairly common sentiment towards Apache from developers who have to deploy their own stuff. I've certainly been in that camp more than a few times in the past. We're talking about:
  - RAM usage
  - Just being slow to push out simple files
  - mod_php being the worst thing ever written
  - mod_python disproving the last statement and taking the crown
  - Various FastCGI/WSGI toolchains just not being up to scratch either.

I moved to nginx and Cherokee and suddenly configuration was both compact and modular and the settings seemed to make a real difference. RAM usage is completely minimal and performance is scorchingly hot. In more than one case I took an Apache box, switched Apache out and we were using half the RAM for the same jobs, and getting better performing websites, with less configuration.

I'm certain Apache could have been tuned but I don't think it's unreasonable for a developer to blame the software if you have to do a three year BSc in Apache Administration just to get something equivalent to 30 minutes playing in nginx.

I truly do hope that things are improving (competition is key in this environment!) but now I've left Apache on multiple servers, they're going to need to do more than just say "If you tune it, it can now match nginx speed", because my time is valuable too. I'm not going to jump back in until for most deployments it "just works".

Re:Apache Never Again (3, Interesting)

hcs_$reboot (1536101) | more than 2 years ago | (#39113397)

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.

Re:Apache Never Again (2)

X.25 (255792) | more than 2 years ago | (#39113767)

I'm certain Apache could have been tuned but I don't think it's unreasonable for a developer to blame the software if you have to do a three year BSc in Apache Administration just to get something equivalent to 30 minutes playing in nginx.

I truly do hope that things are improving (competition is key in this environment!) but now I've left Apache on multiple servers, they're going to need to do more than just say "If you tune it, it can now match nginx speed", because my time is valuable too. I'm not going to jump back in until for most deployments it "just works".

What makes you think that extremely complex piece of software is supposed to be easy to setup, by just about everyone?

Developers can do their development on default setup, I don't see a problem with that.

If you need to use it on production setup (or replication of production setup), then get people who know what they're doing to configure it.

Re:Apache Never Again (1)

BagOBones (574735) | more than 2 years ago | (#39114509)

Apache isn't the application, it the platform that applications are running on... there are many exampled for complex under the hood but easy to manage platforms..

The issue is that the "Default" setup is not performing as well as the "Default" of another product offering the most of the same services.

Not sure what IT department you work in, but many have been cut all to hell in the last few years meaning fewer Experts can be hired and your a left with a small team trying to do everything.

Re:Apache Never Again (5, Insightful)

Anonymous Coward | more than 2 years ago | (#39113961)

+1. Really, it's not even about performance or that Apache guys are bad at software. Far from it. The real crux is that Apache has become the Kitchen Sink of webservers. It can do *anything*, and there's always a complexity cost for that. Nginx can't do everything, but it's a really efficient and minimalist implementation of what 97% of modern deployments actually need, and none of the things they don't.

In some meta-sense, all software goes through this cycle: You're the best, everyone uses you, everyone files niche feature requests, you actually implement all of the niche features, and next thing you know 10 years later you're the Kitchen Sink implementation of domain X, and someone comes along and throws out all the irrelevant bullshit and makes a leaner implementation of just what matters *today*.

IMHO, the answer is that dropping features needs to be as easy as adding them. Too many software projects/architects have an easy-in, hard-out policy on features. "We can't drop feature X, it's been there for years and some crazy people in siberia still use it". It's ok to drop features on major-cycle releases. Perhaps even necessary for long-term project health.

All that and the configuration (1)

Gazzonyx (982402) | more than 2 years ago | (#39114389)

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.

Re:Apache Never Again (2, Interesting)

C_Kode (102755) | more than 2 years ago | (#39113743)

I struggled with Apache 2 for at least 4 years before switching to NginX. It was the best thing I ever did.

You struggled to use Apache?

I appreciate you telling me this. You've enlightened me to add something to my hiring practices. Now I know to ask a simple Apache configuration question when I Interview someone. I definitely don't want to hire someone that has trouble using something as simple as Apache.

Re:Apache Never Again (3, Insightful)

TheNinjaroach (878876) | more than 2 years ago | (#39114243)

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.

Wishfull thinking (0)

stanlyb (1839382) | more than 2 years ago | (#39112341)

That's all i could say.

Re:Wishfull thinking (0)

Anonymous Coward | more than 2 years ago | (#39112443)

And you can't even spell that. How articulate you are.

Re:Wishfull thinking (0)

Anonymous Coward | more than 2 years ago | (#39112523)

Why is it wishful thinking? Nginx isn't magic. There's no reason Apache can't get to the same level of performance.

Re:Wishfull thinking (2)

cababunga (1195153) | more than 2 years ago | (#39113349)

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.

Re:Wishfull thinking (2)

Skapare (16644) | more than 2 years ago | (#39113507)

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).

Apache (0, Funny)

Anonymous Coward | more than 2 years ago | (#39112403)

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.

Re:Apache (0)

Anonymous Coward | more than 2 years ago | (#39112859)

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!

Re:Apache (2, Funny)

Lucky75 (1265142) | more than 2 years ago | (#39112929)

What about easy?

Re:Apache (1)

jamiesan (715069) | more than 2 years ago | (#39112995)

And they can take a lot of hits and still put out?

Re:Apache (1)

pr0nd3xtr (702443) | more than 2 years ago | (#39113165)

Yep just like Rihanna

Re:Apache (5, Funny)

Anonymous Coward | more than 2 years ago | (#39113173)

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 (4, Interesting)

Kohenkatz (1166461) | more than 2 years ago | (#39112473)

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.

Re:Noticeable improvement (1)

Gazzonyx (982402) | more than 2 years ago | (#39114413)

How are you measuring that? Single client, single connection?

Defaults still insane? (4, Informative)

Guspaz (556486) | more than 2 years ago | (#39112527)

Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.

Re:Defaults still insane? (2)

bendilts (1902562) | more than 2 years ago | (#39112645)

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.

Re:Defaults still insane? (3, Informative)

Guspaz (556486) | more than 2 years ago | (#39112955)

There are a handful of workloads that can justify that sort of concurrency, but they're few and far between. Web applications with persistent connections (which you're obviously not doing with that amount of RAM), or serving up large files for download, that sort of thing. The typical case of a LAMP stack almost never requires it, and enormous loads can be handled with levels of concurrency orders of magnitude smaller than what you've got.

People normally thing they want to handle tons of people at the same time, but handling 10x more client requests simultaneously typically means each one takes 10x longer to process; there's no performance advantage, and all you've managed to do is burn RAM.

I won't say that your workload doesn't justify that sort of concurrency, because I don't know what your workload is, but 150 is not a reasonable default for the vast majority of applications. Certainly not for most LAMP installations, where 512MB of RAM is typical, and more than a gig or two is rare.

Re:Defaults still insane? (0)

LearnToSpell (694184) | more than 2 years ago | (#39113231)

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.

Re:Defaults still insane? (2)

Guspaz (556486) | more than 2 years ago | (#39113443)

I wasn't aware that the world's largest server providers were "my mom's basement". If so, perhaps I should move back home, because that sounds like a fucking awesome basement.

For every enterprise customer like you with big iron, there are many more smaller servers. It's like the graphics card industry. Enthusiasts drive the high-end cards, but the vast majority of the market (and profit) is made off the average customer and their iGPU or other low-end part.

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39114465)

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.

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39113387)

I run with 1800 concurrent connections in prod and the apache servers are still basically idling away under full load.

Re:Defaults still insane? (2)

PhrstBrn (751463) | more than 2 years ago | (#39112755)

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.

Re:Defaults still insane? (2)

Guspaz (556486) | more than 2 years ago | (#39112867)

Unless I'm way off the mark, the vast majority of Apache out there (particularly in the environments I mentioned earlier) are running some sort of dynamic module like mod_php.

Re:Defaults still insane? (2)

PhrstBrn (751463) | more than 2 years ago | (#39113005)

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.

Re:Defaults still insane? (1)

Guspaz (556486) | more than 2 years ago | (#39113405)

It's their responsibility because it's a (the?) typical deployment scenario for their software.

Re:Defaults still insane? (1)

PhrstBrn (751463) | more than 2 years ago | (#39113471)

It's the responsibility of mod_php because the typical deployment scenerio has a default that's too high.

Re:Defaults still insane? (2)

Guspaz (556486) | more than 2 years ago | (#39113605)

Actually, you might argue also that it's the distro's fault, since they typically determine the defaults deployed applications will use.

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39113205)

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.

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39112887)

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.

Re:Defaults still insane? (2, Interesting)

Guspaz (556486) | more than 2 years ago | (#39113025)

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.

Re:Defaults still insane? (1)

Anonymous Coward | more than 2 years ago | (#39113337)

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.

Re:Defaults still insane? (0)

Guspaz (556486) | more than 2 years ago | (#39113463)

My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39113483)

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. :)

Re:Defaults still insane? (1)

Guspaz (556486) | more than 2 years ago | (#39113643)

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

Re:Defaults still insane? (2)

silas_moeckel (234313) | more than 2 years ago | (#39113015)

By insane you mean low? 16GB of server ram in a hundred and some bucks. 150 is pitiful try adding at least one zero. Stop buying cheap virtual or low end desktops somebody calls a server and you will not have any issue with the default settings. These numbers were low a decade ago and have not changed since.

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39113115)

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

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39114263)

Buy your own hardware.

Re:Defaults still insane? (1)

Guspaz (556486) | more than 2 years ago | (#39113583)

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?

Re:Defaults still insane? (3, Insightful)

DuckDodgers (541817) | more than 2 years ago | (#39113913)

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.

Re:Defaults still insane? (1)

Terrasque (796014) | more than 2 years ago | (#39114357)

if you need 1500 concurrent connections, then you REALLY should look at event driven web servers [daverecycles.com] .

BTW, for comparison, with cherokee and a uwsgi python uGreen app (used for ajax long-poll comet events) I've successfully tested 1500 connections on a 256mb vserver. It started to go a bit slowly then (1-2 seconds delivering to all clients), but it worked. In normal use I see maybe 150-200 connections to that daemon, and that works splendidly.

It's the difference between a restaurant having a waiter (and in some cases cook) for every customer (and always enough standby to handle peak), and having a few waiters and cooks that instead handle multiple customers.

Re:Defaults still insane? (2, Insightful)

Pionar (620916) | more than 2 years ago | (#39113149)

From reading your post, it seems that the biggest cause is people trying to run web servers who don't know how to and probably shouldn't be.

Re:Defaults still insane? (1)

Guspaz (556486) | more than 2 years ago | (#39113565)

That's not entirely uncommon, no.

Re:Defaults still insane? (0)

Anonymous Coward | more than 2 years ago | (#39114125)

people trying to get the best they can with minimal effort.

Re:Defaults still insane? (1)

Enderandrew (866215) | more than 2 years ago | (#39113257)

Firefox auto-configures settings such as how much memory it can use for caching fully rendered pages. Couldn't Apache in theory look at what mods you have installed, and how much system memory you have and then auto-tune default settings?

Re:Defaults still insane? (1)

Guspaz (556486) | more than 2 years ago | (#39113509)

It could; server admins might not like it, but "reduce maxclients" sounds like a better failure scenario to me than "trigger kernel OOM killer"

Re:Defaults still insane? (1)

dreemernj (859414) | more than 2 years ago | (#39113697)

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.

Re:Defaults still insane? (1)

mspohr (589790) | more than 2 years ago | (#39113861)

So you expect to run Apache without configuring it to your environment?
Defaults are defaults. If you don't have a default configuration, you need to change it.

Re:Defaults still insane? (1)

Guspaz (556486) | more than 2 years ago | (#39113981)

I expect Apache to ship with defaults appropriate for the typical user. In my case, I configured my way to a different web server half a decade ago, due to Apache's various shortcomings.

Re:Defaults still insane? (1)

mspohr (589790) | more than 2 years ago | (#39114325)

I doubt there is a "typical user". Everybody thinks they are a "typical user" but everybody is different. Apache runs on everything from old laptops to large data centers.
It's naive for anyone to install Apache and to assume the defaults will be right for their environment.
"If you assume, you can make an ass out of u and me."

Re:Defaults still insane? (1)

NonUniqueNickname (1459477) | more than 2 years ago | (#39114515)

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.

A bit bitter are we? (4, Informative)

PhrostyMcByte (589271) | more than 2 years ago | (#39112561)

"We also show that as far as true performance is based - real-world performance as seen by the end-user- 2.4 is as fast, and even faster than some of the servers who may be "better" known as being "fast", like nginx," Jagielski said.

What's with the quotes? Other servers have proven to be faster, lighter weight, and more scalable than Apache for a long time. Don't be bitter because you fell behind. Be happy that you're finally catching up.

Re:A bit bitter are we? (2)

bigbangnet (1108411) | more than 2 years ago | (#39112719)

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.

Re:A bit bitter are we? (0)

Anonymous Coward | more than 2 years ago | (#39113209)

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.

Re:A bit bitter are we? (2)

VGPowerlord (621254) | more than 2 years ago | (#39113625)

no, it isn't right to use these quotes when Apache 2.2 (which is what is currently available for production) gets destroyed by nginx / lighty in specific tasks by upto 800%.

Apache 2.4.1 is the version currently available for production [apache.org] , but don't let pesky things like facts stop you.

Re:A bit bitter are we? (2)

phantomfive (622387) | more than 2 years ago | (#39113089)

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.'

Less PR, more innovation (0)

Anonymous Coward | more than 2 years ago | (#39112729)

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 (4, Interesting)

Anonymous Coward | more than 2 years ago | (#39112837)

We need a fully async web server, like nginx, but with *full* support for fastcgi/http1.1 and connection pooling to the backend servers.

In case some people don't know, nginx uses http1 to connect to the servers, which means a new connection for reach request. Same thing for FastCGI. nginx opens a new FastCGI connection for each request, then tears it down once done, even though FastCGI supports persistent connections and true multiplexing.

nginx is awesome and I love competition, especially between opensource.

Re:What we need (0)

Anonymous Coward | more than 2 years ago | (#39113563)

Cherokee ...

Re:What we need (0)

Anonymous Coward | more than 2 years ago | (#39113595)

Lighttpd will do the job nicely, especially on php-cgi support.

Re:What we need (1)

K. S. Kyosuke (729550) | more than 2 years ago | (#39113985)

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.

So?? (0)

Anonymous Coward | more than 2 years ago | (#39113227)

The number one webserver is now going after the #2 webserver.

Interesting trend.

Fixes I'd rather have (3, Interesting)

Skapare (16644) | more than 2 years ago | (#39113373)

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

Here's how to computer the MaxClients value (1)

Anonymous Coward | more than 2 years ago | (#39113619)

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 [lnkd.in] . Nice to see someone actually rolling up there sleeves and actually applying some theory to the problem.

Re:Here's how to computer the MaxClients value (0)

Anonymous Coward | more than 2 years ago | (#39114313)

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".

Ubuntu vs Gentoo (5, Insightful)

inhuman_4 (1294516) | more than 2 years ago | (#39113715)

IANA web admin, but from what I have learned from playing around with both Apache and Nginx is that they serve different markets.

Nginx is a small, fast, reliable web server that is great for virtual machines, home users, newbies (like me), etc. It is simple and "just works" because it make sense. Nginx is the Ubuntu/Mint of the web server world.

Apache is a massive, feature rich, highly tunable, beast that can inter-operate with everything. This is an enterprise class (or at least very serious workload) web server. Designed by people who know what they are doing for people who know what they are doing. Apache is the Slackware/Gentoo of the web server world.

If you need a web server to get a job done, use Nginx. If the web server is your job then Apache. The key is how much time you have to spend figuring out how to customize Apache just right vs. how much those customizations are worth.

Re:Ubuntu vs Gentoo (1)

Anonymous Coward | more than 2 years ago | (#39114245)

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.

Performance? RAM usage? (2)

GioMac (862536) | more than 2 years ago | (#39113825)

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.

Re:Performance? RAM usage? (1)

kervin (64171) | more than 2 years ago | (#39113959)

I'm curious, what MPM are you using? Event MPM?

Re:Performance? RAM usage? (1)

GioMac (862536) | more than 2 years ago | (#39114083)

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.

MOD_PHP any memory changes (0)

Anonymous Coward | more than 2 years ago | (#39113879)

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.

Re:MOD_PHP any memory changes (1)

GioMac (862536) | more than 2 years ago | (#39114011)

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

Re:MOD_PHP any memory changes (1)

GioMac (862536) | more than 2 years ago | (#39114095)

* I mean php module will eat RAM, module itself is small.

Re:MOD_PHP any memory changes (1)

TheNinjaroach (878876) | more than 2 years ago | (#39114339)

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.

The only reason to use Apache is for AJP (0)

Anonymous Coward | more than 2 years ago | (#39114069)

Nginx has an AJP module, but it is third party.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?