Hacker News Reader

Comment by p_l | Hacker News Reader

They consider the Windows + .NET stack to have saved them more money than they pay in licensing et al.

At the time, major "web development" stacks that people would have thought of on Linux tended to be much more resource hungry (still are), meanwhile the people behind StackOverflow had very good .NET skills that they could apply immediately. This translated into being able to serve more people per server than if they used, let's say, PHP, Ruby, Python, etc.

And as people said, SQL Server. Which is a very, very capable database server with impressive performance.

View on HN

I am not sure what your statement is based on regarding linux being more resource hungry than windows. Have stats to back this up? Same for goes for the SQL Server’s “impressive performance”.

The stacks, not the system. At the time StackOverflow was built, the main Linux stacks were either PHP, Rails, Django, or similar, which, while good, are not as performant.

I am puzzled, what are these statements based on? "Linux stacks were either PHP, Rails, Django, or similar, which, while good, are not as performant." - first time I hear a .NET/Windows/SQL Server stack is more performant than these.

The performance of PHP was a joke when Stack Overflow started. It has gotten way better since, but back then it was reading, parsing and compiling every single script your page loaded, for every single page load. You could hack around this with an accelerator module like APC or Zend, but why bother learning how to code around PHPs limitations, when you're already fluent in C# that's plenty fast without any hacking.

Not sure how the story goes for Rails, but Python (Django) used to be a pig when SO was started over a decade ago, for similar reasons as PHP.

> Python (Django) used to be a pig when SO was started over a decade ago, for similar reasons as PHP.

Django's execution model is not at all similar to how PHP code is being run. Pretty much every python web server uses wsgi (or mod_python before that) which relies on a persistent app server. Whatever are the reasons for django's assumed performance issues, PHP's runtime model had nothing to do with it.

PHP performance is still a pig, which is pasted over by various caching behaviours (for example in OS). I have to deal with making HA for a PHP site whose design precludes keeping read-only copies of PHP code, and have to load them form NFS... let's just say that even with php.ini tweaks it involves pretty much constant reads of code.

First time hearing doesn't make it not true. For some historical perspective: MS engaged in a performance battle (which they won) vs Netscape Web Server running on Solaris (with IIS) since 1995 or so, including making changes to the NT kernel. So it wouldn't surprise me this attitude continued forward into the recent era. SQL Server has similarly been in a performance battle with Oracle for decades. MS has whole teams just dedicated to performance, to creating performance engineering tooling etc.

Interestingly, Stack Overflow is using several of those tricks to speed up their internal services, as the kernel-side HTTP server is made available to everyone, it's not locked to MS applications. AFAIK they have few "microservices" which don't use IIS but handle HTTP through HTTP.sys

SQL Server has huge amounts of tuning and cooperation with NTFS driver team to ensure good performance, and frankly, it's at the high-end of the databases, and I really wouldn't mind using it except for price :(

Compiled code is faster than interpreted code. C#.NET is a compiled lamguage and doesn't need to be interpreted at runtime. Making is faster than interpreted languages like PHP, Rails, Python etc. These days, some interpreted languages are now cheating and interpret only at first run. Then skip interpret step on subsequent runs.

C#.NET performance is up there with C++. C#.NET is only slower than C++ during garbage collection. When garbage collection is done, it is back in business and running at the same speed.

> C#.NET is a compiled lamguage and doesn't need to be interpreted at runtime.

That's not a great summary. .Net is complex. There's AOT compilation but not available for all purposes. There's JIT which applies most of the time to C# code compiled into msil. From there different things can happen depending on implementation, which may also include running the code via an IL interpreter.

Doesn't just Mono have an interpreter (which is now being added as part of tiered compilation)? Aside from .NET Micro. I was under the impression that .NET by and large was JIT-only. Yes, by now it's more complex, and there have been multiple different implementations, few of which would be relevant on a Windows Server environment for ASP.NET. But AFAIK a situation like in Java where the official implementation has an interpreter and a JIT (and debugging usually falls back to interpreting with horrible performance) has never been the case in .NET.

last time I checked, AOT is heavily used, and if you load your assemblies into GAC you're getting AOT compilation for pretty much all code if you're not going to generate bytecode at runtime.

C#/.Net/Windows was (is?) at worst as performant than Java/Linux but probably was more performant. Twitter switched from Rails to Java in order to scale up and end their constant whaling, because Rails performance was that terrible.

Put those things together, and it’s fairly evident that C#/.Net greatly outperformed the Django/Rails stacks that were popular at the time.

You forgot JavaEE? Wouldn't that have been the main contender at the time?

1. Their team didn't have expertise with JavaEE.

2. JavaEE??? What has the StackOverflow team done to make you hate them so much? :o)

Reply on news.ycombinator.com