"(...)When I compare our performance to similar sites that are running on the open source stack, we are using about 1/10th of the hardware that they are, unfortunately, and maybe that’s because they are not good programmers. But just in terms of the types of queries we are doing and stuff, the Microsoft stack is actually, appears to be paying for itself – in terms of reduced hardware”
Doesn't really provide any real justifications. I have indeed anecdotally heard good things about mssql, but apart from that I have a hard time believing you couldn't get more or less identical performance from jvm/linux/etc (and maybe mysql/postgres really can give mssql a run for its money, but I admittedly know little about relative database performance)
On the other hand, it seems like Jeff/Joel had lots of experience with the MS stack before, so its not an illogical choice. You want to spend your time building a product, not wasting it figuring a new stack you aren't very familiar with.
I've been through the gambit of making heavily used applications under ASP, ASP.NET, CakePHP, and Django. Part of what comes up in these kinds of discussions has to do with how a .NET website works vs how a "Linux" website works.
The difference in performance per hardware dollar for a .NET setup and a Linux type setup can be quite large. Especially if you compare an ASP.NET site to a PHP site. The .NET stuff is going to be compiled, or at least pre-parsed, and likely jitted. To get comparable performance out of PHP, you'd need to use APC or Zend or something similar. For small sites the difference may not be all that large. But if you're using something like CakePHP, there can be a good amount of stuff for the server to parse on every single request.
Also a dead simple dumb LAMP setup is going to use Apache prefork, and won't have nearly as good scalability for the same amount of memory as an ASP.NET setup would. A naive Linux PHP setup is actually more like what the ancient, pre-.NET world of ASP looked like.
So in short, ASP.NET is going to blow the doors off of a dead simple LAMP setup if you have a huge amount of code and don't use Zend or APC. A more modern setup under Linux would do much better of course, say Python and WSGI use Apache-worker. This setup is going to give much better performance (due to not having to precompilation) and make better use of memory (through threads in apache-worker vs what you get with apache-prefork).
Microsoft's technologies come out of the box building higher performance apps in the default configuration than some of the more naive pure-Linux approaches.
I've personally observed huge boosts in the number of concurrent connections a machine can handle with Apache-worker vs Apache-prefork. I've personally observed PHP applications going into fairly high CPU use, and then settling down a lot once I installed APC (which prevents the machine from having the parse the PHP on every request). It's not conjecture, it's observation. I also know that due to the nature of how .NET apps work, they never have that kind of problem. Neither do most other modern web frameworks. Sorry I don't have the graphs-- I don't use Microsoft apps any more. Good day!
"(...)When I compare our performance to similar sites that are running on the open source stack, we are using about 1/10th of the hardware that they are, unfortunately, and maybe that’s because they are not good programmers. But just in terms of the types of queries we are doing and stuff, the Microsoft stack is actually, appears to be paying for itself – in terms of reduced hardware”
Doesn't really provide any real justifications. I have indeed anecdotally heard good things about mssql, but apart from that I have a hard time believing you couldn't get more or less identical performance from jvm/linux/etc (and maybe mysql/postgres really can give mssql a run for its money, but I admittedly know little about relative database performance)
On the other hand, it seems like Jeff/Joel had lots of experience with the MS stack before, so its not an illogical choice. You want to spend your time building a product, not wasting it figuring a new stack you aren't very familiar with.