One of the early signs on maturity in the IT space. A 4 year upgrade cycle is about the same for the automobile industry now.
The Apache Software Foundation has issued the first upgrade to its popular HTTP server platform in six years. "It is with great pleasure that we announce the availability of Apache HTTP Server 2.4", said Eric Covener, vice president of the Apache HTTP Server Project, in a statement. "This release delivers a host of …
The Apache web server is in the fortunate position of not having a marketing department breathing down its back for new Big Releases every six months. So no pressure to whack up the version numbers. As indeed is common amongst the best projects: the Linux kernel has been at 2.x even longer than apache, despite all the evolution in the hardware under it.
But this doesn't mean things stayed the same for six years. Apache's modular framework makes it straightforward to add new goodness outside the core, or in core with only a delta-version bump. The only absolute rule of delta releases is that we don't break API or ABI back-compatibility within a stable branch such as 2.4.x.
Used to work for a bank in IT. The IT Director was passionately anti-open source. All the traders used Samba of course to connect their Sun workstations to the Windows network. I think he must have just closed his eyes and stuck his fingers in his ears when on the trading floors so he could continue to insist that OS was "bad" and they would not use it anywhere.
If Linux isn't Unix then using the term 'Unix' is meaningless. Flavours of Unix such as HP/UX, Solaris, AIX are as far apart from each other as Linux is from Unix. Any competent
Unix admin can turn their hand to Linux. Any competent Linux admin *should* be able to turn their hand to Unix, but that bit doesn't seem to be universally true.
Chances are high that you'll always find your way towards Apache.
What I came to love and respect from Apache is its ease of use and its versatility. What may look like a boring and tedious way to configure your webserver (editing one or more plain text config files) is actually the most flexible way to do this. Esp. when you're operating with multiple websites.
Think about it; a nice "IIS like" wizard can be very helpful, sure. But how much fun is it going to be if you end up having to supply the exact same information again and again while you could as easily have performed a copy/paste with a text editor (and make the required changes afterwards, thus leaving the parts which are equal) ?
I started out with Apache myself, then I grew a liking towards Sun's JavaONE webserver (webserver with an 'embedded' Java engine, based on Netscape's iPlanet server). It was fun, I still hold it in high esteem but no longer use it. Supported both web interface as well as config files. But as soon as you started to edit stuff manually it quickly became tedious. No fun having to deal with XML in vi IMO.
Alas, I played a while with Apache on Windows, added Tomcat to the mix but that one's just not for me. And here Apache shows you just how extensive it can be; right now I'm experimenting with ASP out of all things. Apache has me covered there as well! Full front end server and all ASP snippets are easily proxied onto a backend IIS Express server.
IMO Apache is truly and by far one of the best webservers out there, and not just for Linux / Unix machines. Even on Windows it does a very impressive and remarkable job IMO.
The main difference is "apachectl configtest / apachectl graceful" vs. "httpd -t" / "httpd -k restart".
Well, and me starting metapad instead of vi :-)
Thanks for the patronising advice about copying files, but what you're talking about (ignoring the irrelevant look-what-I've-done stuff,) seems fairly similar to
Need to take your blinkers off, I'd say ...
OTOH, the darkest times of helpless despair and groveling at the feet of the Beast are indeed upon us when people need a howto about copying configuration files over.
Biblical apocalyptic genocide at the command of Jehova icon is missing? Nuke will do.
At least in comparison with past versions of Apache, Nginx has been shown to perform better at handling a high number of concurrent connections with a lower memory footprint. And you can upgrade executable and configs concurrently - without client connections loss. So probably it was competition that prompted the upgrade move.
You could even write it using more sensationalist headlines: "Apache Foundation outgunned by SysAdmin from Kazakhstan - LAMP becomes LEMP - why did Europe's SysAdmins not have this idea?"
> Nginx has been shown to perform better at handling a high number of concurrent connections
> with a lower memory footprint
That's only important if your site is suffering from a performance issue or is memory-constrained. Hardware is cheap, and most sites don't get nearly enough traffic to worry about this sort of thing.
Nginx has a long way to go before it has anything like Apache's feature set. There are a lot of experienced Apache administrators. Apache's a mature product that gets tested very extensively in the field. Those are three reasons to choose Apache over Nginx.
I have nothing against Nginx, but its performance advantage is far from a compelling reason to switch for most Apache users.
Yes it is. It is pretty feature complete. For example, and I'll admit this example is pretty esoteric, can it (NGINX) reverse proxy an Activsync thingie.
Imagine my surprise when I tested out a (Novell/Attachmate) GroupWise system with Datasync and an Apache reverse proxy on the front and found it "fooling" MS's Exchange connectivity tester into thinking it was talking to an Exchange server's OWA n Activsync. My company 'droid's and iThangs are quite happy with it as well.
Oh and the Kerberos support through mod_kerb means that IIS just doesn't have a place in my world. Unless my customer really insists, and then I get to charge for the extra faffing around - I win in £££s and they get what they want.
Apache is the web server that just keeps on serving. No its not perfect, that's why development continues but its very, very good.
The first thing to realize is that for most web servers, the speed of the webserver itself is immaterial. You typically find you will reach the limits of your database server or your network before the web server becomes slightly important.
The second thing to realize is that benchmarks 'showing' nginx to be faster than httpd are largely incorrect, or rather, are a result of a poorly configured httpd. One of the biggest complaints about httpd performance was the performance under the prefork MPM, which was typically chosen as the default MPM by distributors.
The MPM determines how httpd runs. The prefork MPM has one master process, which forks child processes and allocates requests sequentially to the children. It's how webservers worked 20 years ago, and allows things like PHP, which have non thread safe extensions, run safely embedded in the webserver - which is why distros choose it as a 'slow but works' default.
A better choice for MPM are the worker and event MPMs. The worker MPM has a hybrid multi-proces/multi-thread model, which massively increases performance, and the event MPM is similar, but has dedicated threads for handling KeepAlives. These don't work well with things like mod_php, but then neither does nginx - you don't get mod_foo for nginx. Instead, with nginx and httpd-event, you run your PHP and python web apps via FCGI/WSGI.
In 2.4 MPMs are now loadable, so the choice of the distro maintainer no longer limits you. The other big thing is that event MPM is no longer 'experimental' as it was throughout the 2.2 series - although that didn't stop us running it in production for the last 5 years. The third highlight is mod_proxy_fcgi, which allows you to dispense of webservers on your backend app servers when using httpd as a front end proxy.
When httpd is configured like this, it is easily on a par with nginx.
Biting the hand that feeds IT © 1998–2019