Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
The Internet Upgrades Apache

Apache 2.4 Takes Direct Aim At Nginx 209

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

Apache 2.4 Takes Direct Aim At Nginx

Comments Filter:
  • by Kohenkatz ( 1166461 ) on Tuesday February 21, 2012 @12:46PM (#39112473) Journal
    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.
  • What we need (Score:4, Interesting)

    by Anonymous Coward on Tuesday February 21, 2012 @01:11PM (#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.

  • by OliWarner ( 1529079 ) on Tuesday February 21, 2012 @01:19PM (#39112957) Homepage

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

  • by Guspaz ( 556486 ) on Tuesday February 21, 2012 @01:23PM (#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.

  • by Skapare ( 16644 ) on Tuesday February 21, 2012 @01:46PM (#39113373) Homepage

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

  • by hcs_$reboot ( 1536101 ) on Tuesday February 21, 2012 @01:47PM (#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.
  • by C_Kode ( 102755 ) on Tuesday February 21, 2012 @02:12PM (#39113743) Journal

    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.

8 Catfish = 1 Octo-puss

Working...