5 ms·

Yeah that's my point - if they were using a slower language they'd be clocking in at say 20 or 30 servers. Not remotely worth optimizing for saving that many se

by nfm 12y ago

Yeah that's my point - if they were using a slower language they'd be clocking in at say 20 or 30 servers. Not remotely worth optimizing for saving that many servers at their scale.

juliangregorian 12y ago
Not necessarily, because code is seldom the bottleneck in these types of scenarios, it's network, file IO, or DB transactions. Not to mention that most websites of this nature typically deploy some type of caching layer long before they reach 9 app servers.
alexchamberlain 12y ago
Sorry if I misunderstood, but I don't believe they chose C# for its performance characteristics: I believe that they chose it as it was the best choice at the time; a lot has changed since the advent of Stack Overflow. Similar reason that a lot of Amazon is C and/or C++. I can't find any references for this, however.
- codingthebeach 12y ago
  I don't think they would've chosen C# at all were it not for ASP.NET MVC. It was the MVC, more than anything else, that made lean-and-mean WISA stacks possible. C# with ASP.NET MVC under recent versions of Visual Studio is tooled to the Nth degree, performant, and yet and manages to stay clean. Not so under ASP.NET WebForms and even less so under classic ASP.
  - mattmanser 12y ago
    They used c# because Jeff Atwood was a c# developer. 8 or 9 years ago it was a lot less common to be effortlessly multilingual, changing stack was a lot of effort. Mainly because SO didn't exist! So you had to hunt through reams of text to find answers to simple questions, that now you google and the exact question has been asked on SO and answered. I can't emphasise how painful switching languages used to be. I suspect if asp.net MVC hadn't been out, it would have been written in webforms. I seem to remember asp.net MVC had only been out a couple of months when they started writing it or not even fully released, I was learning django at the time because MVC so was so obviously better than webforms. But because c# was so much faster than either ruby or python, when asp.net MVC turned up, and it was very, very good for a v1, I stuck with c#, as did many other .net programmers I suspect. At the time SO was written rails and django were still new and slowwwwww, php was king and still mainly written by page without frameworks, Java who knows, and the MVC revolution was just starting. I'm not sure what you think he would have written it in? I have a feeling if you hunt through coding horror you'll probably find a post from the SO start time period saying "use what you know". In Jeff Atwood's case that's C#. I know that Joel's company had written their own language that I think at the time was still in use, so they wouldn't use the fog creek stack. Which was still based on Microsoft stuff anyway.
    - jghn 12y ago
      I think you're really overselling the difficulty of switching languages at that time, it wasn't even that big of a deal pre-google, much less pre-SO. That said, SO was indeed a complete game changer in terms of the rapidity with which one could get solid information.
      - mattmanser 12y ago
        There were a lot less tutorials, they tended to be for Linux/Mac, it was rare to find windows installers, some python libraries didn't work at all on windows without some seriously complicated compiler knowledge. It might have been easy to go php > ruby, but C# > ruby meant massive amounts of pain or complety changing your environments. While my company at the time had VMs, they were all windows and it wasn't a case of simply spinning up an EC2 to play. The pain of leaving a MS stack was massive. I'm using ruby/python a bit interchangeably as I was.playing with both, but even things like gem took a load of effot compared to now. Like a couple of days of fiddling doing nothing interesting, not programming but constantly hitting errors or tutorials not working as you'd got a step earlier in the chain slightly wrong. It was a huge barrier to entry. The worst tutorials claimed to be for both windows and linux, but would link to an out of date windows installer and all the command line commands would be for linux. I once made the mistake of thinking I'd write little maintenance scripts in Python instead of VB, it was great until I tried to connect to a MSSQL environment, ended up in a world of pain. Last time I span up node.js on a new windows computer it took me like 10 minutes. Everything has changed.
        jghn 12y ago
        I can't speak to anything regarding Windows dev here as I haven't done any of that since the mid-90s, and even then it was just a short project. That said, I see what you're getting at now and it isn't what I thought you were talking about previously. It looks like what you're talking about is it taking a few days (or so) to get a working environment up and running vs. nearly instantaneous now? If so, fair enough I totally agree. I thought you were talking more about the more nuts & bolts parts, like it taking a few weeks to come up to speed on Python (for instance) instead of several months. I've always felt that claims of it being difficult to change languages or other type things (e.g. changing from Oracle to MySQL) were radically overblown, and these days w/ sites like SO it's pretty much trivial.
barrkel 12y ago
I'm confident that the performance multiple from C# to Ruby is comfortably greater than 2-3x. But the specifics are heavily dependent on the actual code executed; to a first approximation, most Rails code is shuffling parameters to and from a database. It's very difficult to speculate. If most of your Ruby code, to take an example, is effectively a wrapper around native code (e.g. regular expressions or string substitution in templates), then the win from using something like C# or Java is probably low.
- nfm 12y ago
  I don't think there's much point nit-picking on multiples - who knows for sure without seeing their code - but my point still stands. Would you have been surprised if StackExchange ran on 50 or 60 front-end servers? I certainly wouldn't have. And that would be the equivalent of being able to take 200ms a response for the same amount of traffic. In ruby/rails that's a pretty horrible end goal. GitHub's mean web response time is currently 57ms, for example.
  - barrkel 12y ago
    I would have been surprised to learn it was on 50 or 60 servers. I'm a little bit disappointed to learn that it requires 9, as I had thought of them as one of the last bastions of scale up rather than scale out, but 9 is approaching a large number. I think the complexity costs of scaling out are underestimated; or rather, they're just accepted as a fact of the matter, like there isn't an alternative. More moving parts in the name of redundancy etc. usually makes things more fragile, without very careful design and implementation. Interesting that you bring up GitHub. GitHub was probably the most unreliable service our startup used before we moved to Stash. You could count on it being down for a few hours every month, reason given usually "DDoS". We moved to Stash for contractual reasons relating to security and ISO certification required by our target sector, finance, but I could see us having done it for reliability too.
    - jsmeaton 12y ago
      From memory StackOverflow itself only runs on 2 web servers. The rest are for various other stackexchange properties. You'll also note that peak CPU is about 20%, so they could probably run everything on 2 or 3 servers at max CPU (bad!). But they could easily halve the number of webservers and stay performant (but not fault tolerant).
lazyjones 12y ago
> if they were using a slower language they'd be clocking in at say 20 or 30 servers. Not remotely worth optimizing for saving that many servers at their scale. If they were using a slower language, they'd get much higher latencies (maybe 200-300ms instead of 33ms) that couldn't be fixed no matter how many servers they add. If you read the linked page and Nick Craver's blog carefully, you'll notice that they're deliberately aiming for very low latencies everywhere.
- scott_w 12y ago
  Considering I've seen a Django app loading pages within 100ms (including database queries but with some caching), the 300ms estimate is a little off the mark here. As with all things, you have to measure it for your own application and find your bottlenecks before drawing conclusions.
nine_k 12y ago
A statically-typed, compiled language with libraries for everything also saves you debugging and development time (yes, development). Beside that, what matters here is not throughput but user-visible latency. And here's where a fast language shines.

by nfm 12y ago

Yeah that's my point - if they were using a slower language they'd be clocking in at say 20 or 30 servers. Not remotely worth optimizing for saving that many servers at their scale.

juliangregorian 12y ago

Not necessarily, because code is seldom the bottleneck in these types of scenarios, it's network, file IO, or DB transactions. Not to mention that most websites of this nature typically deploy some type of caching layer long before they reach 9 app servers.

alexchamberlain 12y ago

Sorry if I misunderstood, but I don't believe they chose C# for its performance characteristics: I believe that they chose it as it was the best choice at the time; a lot has changed since the advent of Stack Overflow. Similar reason that a lot of Amazon is C and/or C++. I can't find any references for this, however.

codingthebeach 12y ago
I don't think they would've chosen C# at all were it not for ASP.NET MVC. It was the MVC, more than anything else, that made lean-and-mean WISA stacks possible. C# with ASP.NET MVC under recent versions of Visual Studio is tooled to the Nth degree, performant, and yet and manages to stay clean. Not so under ASP.NET WebForms and even less so under classic ASP.
- mattmanser 12y ago
  They used c# because Jeff Atwood was a c# developer. 8 or 9 years ago it was a lot less common to be effortlessly multilingual, changing stack was a lot of effort. Mainly because SO didn't exist! So you had to hunt through reams of text to find answers to simple questions, that now you google and the exact question has been asked on SO and answered. I can't emphasise how painful switching languages used to be. I suspect if asp.net MVC hadn't been out, it would have been written in webforms. I seem to remember asp.net MVC had only been out a couple of months when they started writing it or not even fully released, I was learning django at the time because MVC so was so obviously better than webforms. But because c# was so much faster than either ruby or python, when asp.net MVC turned up, and it was very, very good for a v1, I stuck with c#, as did many other .net programmers I suspect. At the time SO was written rails and django were still new and slowwwwww, php was king and still mainly written by page without frameworks, Java who knows, and the MVC revolution was just starting. I'm not sure what you think he would have written it in? I have a feeling if you hunt through coding horror you'll probably find a post from the SO start time period saying "use what you know". In Jeff Atwood's case that's C#. I know that Joel's company had written their own language that I think at the time was still in use, so they wouldn't use the fog creek stack. Which was still based on Microsoft stuff anyway.
  - jghn 12y ago
    I think you're really overselling the difficulty of switching languages at that time, it wasn't even that big of a deal pre-google, much less pre-SO. That said, SO was indeed a complete game changer in terms of the rapidity with which one could get solid information.
    - mattmanser 12y ago
      There were a lot less tutorials, they tended to be for Linux/Mac, it was rare to find windows installers, some python libraries didn't work at all on windows without some seriously complicated compiler knowledge. It might have been easy to go php > ruby, but C# > ruby meant massive amounts of pain or complety changing your environments. While my company at the time had VMs, they were all windows and it wasn't a case of simply spinning up an EC2 to play. The pain of leaving a MS stack was massive. I'm using ruby/python a bit interchangeably as I was.playing with both, but even things like gem took a load of effot compared to now. Like a couple of days of fiddling doing nothing interesting, not programming but constantly hitting errors or tutorials not working as you'd got a step earlier in the chain slightly wrong. It was a huge barrier to entry. The worst tutorials claimed to be for both windows and linux, but would link to an out of date windows installer and all the command line commands would be for linux. I once made the mistake of thinking I'd write little maintenance scripts in Python instead of VB, it was great until I tried to connect to a MSSQL environment, ended up in a world of pain. Last time I span up node.js on a new windows computer it took me like 10 minutes. Everything has changed.
      - jghn 12y ago
        I can't speak to anything regarding Windows dev here as I haven't done any of that since the mid-90s, and even then it was just a short project. That said, I see what you're getting at now and it isn't what I thought you were talking about previously. It looks like what you're talking about is it taking a few days (or so) to get a working environment up and running vs. nearly instantaneous now? If so, fair enough I totally agree. I thought you were talking more about the more nuts & bolts parts, like it taking a few weeks to come up to speed on Python (for instance) instead of several months. I've always felt that claims of it being difficult to change languages or other type things (e.g. changing from Oracle to MySQL) were radically overblown, and these days w/ sites like SO it's pretty much trivial.

barrkel 12y ago

I'm confident that the performance multiple from C# to Ruby is comfortably greater than 2-3x. But the specifics are heavily dependent on the actual code executed; to a first approximation, most Rails code is shuffling parameters to and from a database. It's very difficult to speculate. If most of your Ruby code, to take an example, is effectively a wrapper around native code (e.g. regular expressions or string substitution in templates), then the win from using something like C# or Java is probably low.

nfm 12y ago
I don't think there's much point nit-picking on multiples - who knows for sure without seeing their code - but my point still stands. Would you have been surprised if StackExchange ran on 50 or 60 front-end servers? I certainly wouldn't have. And that would be the equivalent of being able to take 200ms a response for the same amount of traffic. In ruby/rails that's a pretty horrible end goal. GitHub's mean web response time is currently 57ms, for example.
- barrkel 12y ago
  I would have been surprised to learn it was on 50 or 60 servers. I'm a little bit disappointed to learn that it requires 9, as I had thought of them as one of the last bastions of scale up rather than scale out, but 9 is approaching a large number. I think the complexity costs of scaling out are underestimated; or rather, they're just accepted as a fact of the matter, like there isn't an alternative. More moving parts in the name of redundancy etc. usually makes things more fragile, without very careful design and implementation. Interesting that you bring up GitHub. GitHub was probably the most unreliable service our startup used before we moved to Stash. You could count on it being down for a few hours every month, reason given usually "DDoS". We moved to Stash for contractual reasons relating to security and ISO certification required by our target sector, finance, but I could see us having done it for reliability too.
  - jsmeaton 12y ago
    From memory StackOverflow itself only runs on 2 web servers. The rest are for various other stackexchange properties. You'll also note that peak CPU is about 20%, so they could probably run everything on 2 or 3 servers at max CPU (bad!). But they could easily halve the number of webservers and stay performant (but not fault tolerant).

lazyjones 12y ago

> if they were using a slower language they'd be clocking in at say 20 or 30 servers. Not remotely worth optimizing for saving that many servers at their scale. If they were using a slower language, they'd get much higher latencies (maybe 200-300ms instead of 33ms) that couldn't be fixed no matter how many servers they add. If you read the linked page and Nick Craver's blog carefully, you'll notice that they're deliberately aiming for very low latencies everywhere.

scott_w 12y ago
Considering I've seen a Django app loading pages within 100ms (including database queries but with some caching), the 300ms estimate is a little off the mark here. As with all things, you have to measure it for your own application and find your bottlenecks before drawing conclusions.

nine_k 12y ago

A statically-typed, compiled language with libraries for everything also saves you debugging and development time (yes, development). Beside that, what matters here is not throughput but user-visible latency. And here's where a fast language shines.