6 ms·

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

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.

trilila 7y ago
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.
- nikanj 7y ago
  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.
  - viraptor 7y ago
    > 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.
  - p_l 7y ago
    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.
- dboreham 7y ago
  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.
  - p_l 7y ago
    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 :(
- madiathomas 7y ago
  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.
  - viraptor 7y ago
    > 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.
    - ygra 7y ago
      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.
    - p_l 7y ago
      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.
- addicted 7y ago
  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.
rightbyte 7y ago
You forgot JavaEE? Wouldn't that have been the main contender at the time?
- oblio 7y ago
  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)

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.

trilila 7y ago

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.

nikanj 7y ago
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.
- viraptor 7y ago
  > 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.
- p_l 7y ago
  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.
dboreham 7y ago
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.
- p_l 7y ago
  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 :(
madiathomas 7y ago
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.
- viraptor 7y ago
  > 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.
  - ygra 7y ago
    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.
  - p_l 7y ago
    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.
addicted 7y ago
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.

rightbyte 7y ago

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

oblio 7y ago
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)