June 2011 Web Server Survey
news.netcraft.com
news.netcraft.com
Comparing the two over all domains is ridiculous as this includes mass domains such as parked domains which can easily give Apache 10s of millions of useless stat points as one registrar switches a couple of servers.
The very last graph is the most sensible one which compares the two over the top 1 million domains and shows IIS to have a relatively stable share over time.
A better graph would compare the top 100,000 sites running on dedicated IPs or servers (no shared hosting accounts) that have existed for at least 6 months.
My suggestion with removing the shared hosting accounts was just a way to remove noise from the dataset so we are truly comparing apples to apples rather than apples to oranges... Otherwise you could end up seeing IIS loose in a market space that it never was in (and never will be in) because Apache gained in it.
It was just a suggestion. You could leave shared hosting in.
That may not be a particularly useful metric in business terms, but it is at least a fair comparison.
People create these stats for a reason. If the reason is to show that one side or the other is "losing", whatever that means, they should go ahead and chose whatever they want. (I am not implying that's what you were saying or anything).
On the other hand, if the point is to educate people on which software is more used in a meaningful sense, the article would be better if it had the grandparent's explanation at the top, explaining why the comparison should be done only in one specific market, and then do the comparison in that market. I for one wouldn't have thought about it, and gotten the wrong impression.
The purpose of collecting these stats is not to find out how IIS is doing in it's target market, but instead to find out how popular web servers are.
If I were to suggest removing all non-Free OSs from the statistics (since one could claim that as a Free web server Apache doesn't compete there), then you'd see totally different numbers aswell, and that would just as deceptive.
Also note that the original title posted here was something like : "IIS loses market share, it sucks, down to 1998 levels."
The market that Microsoft directly competes in (using
IIS) has never been anywhere near the shared hosting
space
That's not from a lack of trying on Microsoft's part.And eliminating shared-hosting from a statistic like this is exactly how Microsoft would do it - introducing bias to turn the numbers in their favor.
Does EC2 count as shared hosting btw? What about Heroku?
to remove noise from the dataset
Sure, I'm all for removing parked domains. But there are lots of business and professionals that have their website hosted with shared accounts, websites that are useful for their target audience, even though they may not be in the TOP-whatever. Excluding those websites from such a metric would do a disservice to people. Otherwise you could end up seeing IIS loose in a
market space that it never was in
Or you could say that you would see IIS win in a market space that's getting crushed by shared hosting.It's a comparison of popularity between similar front-end web servers, which does have something to say about cost and feasibility of hosting multiple websites on top of cheap servers. Otherwise the comparison is useless, as popularity doesn't really matter to big corporations and startups that know what they are doing and are likely to choose Nginx anyway.
The sample is self-selecting. Since you pretty much can't do shared hosting on it, IIS competes in a segment that doesn't use shared hosting.
If you select enough your sample you'll end up with one that supports the theory IIS is The Greatest Web Server That Ever Was.
I choose the latter.
No one is suggesting reducing the sample further down with cherry picking.
Personally I like Apache for bulk hosting. It's easy to write scripts that can deploy thousands of sites. There's a scripting interface to IIS that would let you do that too, but it's just so easy to write a script that prints lines into a configuration file.
There are a lot of things to explain in that graph. Assuming that an anomaly in Netcraft doesn't explain some of the bumps it seems like there were a lot of drops in the year after the 2008 financial crisis and also it seems like someone's gone bananas registering names in the last few years.
If we are counting web server use, and mass domains are an example of web server use, you would need to say more than just 'mass domains are useless'. Otherwise that is just special pleading.
On the other hand, if we are counting 'useful domains', you would need to say why you think mass domains don't count as 'useful'. You only said that they could switch often.
I would say mass domains count as a 'useful' because they still have some kind of exposure security wise. They also demonstrate provisioning costs (or lack thereof) and provisioning speed.
Netcraft has been at it basically as long as I have. I don't read their survey reports regularly but maybe I should. Their archives are awesome. Remember the SCO saga?
http://news.netcraft.com/archives/2003/12/15/outages_continu...
Thanks Netcraft!
Also, I love their anachronistic logo.
If the data can be trusted, it's interesting that IIS has basically been flat from 1998 'til now, with an upward deviation every once in a while.
This headline seems link bait-y. "Apach the only serious player". Really? When IIS has ~ 20% share? So, Apple must not be a serious player in the desktop/laptop market, since their share is in that ballpark.
Another web server project I quite like is Cherokee (http://www.cherokee-project.com/) - it's got a lot of features but still manages to beat Apache, lighthttpd and nginx in a lot of benchmarks. It's got quite a nice web interface to control it too but it's a bit annoying to not have configuration files for automated setups...
I guess my question being, how would you convince people to use your favorite stack, and sometimes the best service for the job, such as Nginx/PostgreSQL, when all they know is the most popular services. Sometimes, just convincing them it's the best for the job is not enough.
Doesn't look bad at all. ~10 required lines, all of which are just telling nginx how to call wsgi and what params to pass.
Very similar to the apache config to do the exact same thing.
Also, read this: http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx...
mod_wsgi is an interesting example. Surely it has the wrong architecture for Nginx and something better could surely be written. But mod_wsgi for Apache simply kicks ass, being a server that manages everything for you with low overhead and good performance caracteristics. No need for supervisord or any of that crap.
Some people go as far as recommending running Nginx in front of Apache, with all the overhead that brings, just for mod_wsgi (although the same could be said about mod_php).
That's the thing about Apache - it's so mature and has so much traction that you can find quality plugins for anything and everything, being an all you can eat buffet.
But then if you're going to put Nginx in front of Apache, why go with Nginx instead of Varnish: http://www.varnish-cache.org/ -- which is designed from the ground-up to function as a high-performance proxy cache (the Nginx plugin for proxy caching sucks donkey balls IMHO)
What I'm trying to say here is that Nginx is very far from a one-size-fits-all. It's awesome for at least one website I've got written in Ruby on Rails and I'm using it in combination with Passenger (Ruby's mod_wsgi).
But for all my other use-cases, I'm starting with Apache first, then reconsider the move to Nginx or not.
I'll switch to nginx as soon as that situation changes.
That said, someone who knows more about configuring Apache for performance likely would not have this problem. I'm just a developer throwing up a blog, however, and switching to nginx was quicker than figuring out how to make Apache work better.
Feedback appreciated.
Server:Microsoft-IIS/6.0
X-AspNet-Version:2.0.50727
X-Powered-By:ASP.NETThat may be part of the deal.
Note: We wrote an IIS-based proxy that masked away the Java-ness of the application and replaced it with .NET-ness. Worked perfectly.
Must have been expensive.