Possible Duplicates:
What are the architecture details of Stackoverflow?
What was Stack Overflow built with?
Where can I find articles introducing the architecture or technologies used by Stack Overflow? I want to know what makes SO so fast.
-
3Because it runs on ponies :o– GManNickGDec 1, 2009 at 5:31
-
In before it is downranked. My comment may not qualify as an answer, it is probably because of high quality of Microsoft platform/stack/backend and lots of work done by paid developers. Perhaps very careful usage of open source (if any) helped too.– user139323Dec 1, 2009 at 5:32
-
Why is atackoverflow so fast? You're obviously not counting the time it takes to access the ad and gravatar servers, then.– paviumDec 1, 2009 at 5:32
-
Very very well written piece of software, that is for sure.– MuraliDec 1, 2009 at 5:34
-
2Because it is powered by the minds of Jon Skeet, Jeff Atwood and Joel Spolsky. The Three J's have immense mental capability, and along with Jon's foresight of knowing what you will ask before you ask, the site can just flies along.– BinaryMisfitDec 1, 2009 at 5:38
-
dupe: meta.stackexchange.com/questions/2498/…– PollyannaDec 1, 2009 at 5:38
-
Probably developers who really know what they are doing. The best platform / backend in the world won't help if the developers don't understand how to build a scalable system using them.– Stephen CDec 1, 2009 at 5:41
-
1@Gman: You meant unicorns.– casperOneNov 11, 2011 at 13:08
Add a comment
|
1 Answer
We made some modifications to ASP.NET:
But seriously,
- start with a fast stack (avoid interpreted code, like PHP)
- stick with the same "family" of stuff that is designed and tested heavily to work together. In our case that is IIS7, Win2008, SQL Server, ASP.NET.
- frequently use profilers to see where you're slow: SQL Profilers, Firebug traces, .NET profiler.
- keep iteratively fixing the slowest parts until you get rid of all the low hanging fruit, performance-wise
- consider rearchitecting if you hit a wall in performance due to poor architecture choices made early on (we did this on the DB side once, to reduce joins)
- hardware is cheap, programmers are expensive: buy nice, fast hardware because it costs mouse nuts in the big scheme of things.
- realize that performance is a feature and weight your development time accordingly (this is the biggest problem I've seen in the past on dev teams; performance is always "whenever we get to it" and that ends up being never)
answered Dec 1, 2009 at 5:39
-
Bleh. Now your gonna make me re-open this question, aren't you? <mumble>You always find a way to steal my thunder</mumble> Dec 1, 2009 at 5:43
-