Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Over the past couple of days, I have noticed that Stack Overflow is faster than ever. This is severely affecting my thumb twiddling time. When am I supposed to practice my thumb twiddling if I don't have to wait for the pages to load?? Please think of the thumb twiddlers when considering future performance enhancements!
Um... since you're endorsing [always-friday-in-iceland], would it be possible to remove the synonym from [fun]? pretty please? I know how to get around it with chain synonyms, but that only works once, and then upon editing, you have to manually retag it every time.
@George It didn't. However, before that synonym was created, a few synonyms to [afii] were created, such as [always-hydrogen-on-friday]. The synonym system doesn't chain retag, so if you use that tag, you get [afii]. However, when the post is edited again... the synonym system sees [afii] and retags it to [fun].
@Rebecca yeah, that's a good idea! Good to see such things here, and the unicorns here and there. BTW what's this character you're using ‽? Where did you find it?
We looked closely at performance over the last few weeks, particularly in the last 4 or 5 business days.
we reduced the total number of queries happening on a lot of pages (question show, question lists, user page, etc.)
we deployed a page that shows us our worst query offenders in CPU time, total duration, reads, writes, etc. and optimized the stuff at the top of the lists
we improved the way we call LINQ to SQL and moved to pre-compiled LINQ queries in certain hot code paths. This seems to have gotten much faster in .NET 4.0, we saw 8x gains over plain vanilla LINQ and 2x over SQL-queries-as-LINQ-returns.
we reduced the number of columns we return in some hot code paths, where we had effectively select * from users and posts.
we were getting sloppy about the way we handled search engines, which was causing a lot of undue load -- Google's crawler is now indexing us at, and I am not making this up, 10 requests per second which is the maximum. This is confirmed in Google Webmaster Tools. Google doesn't need all the same work done per page that, say, a user does -- and when Google hits thousands of pages in a few minutes, that can kick off a lot of background work, such as rebuilding related questions. Not expensive by itself, but when multiplied by a hundred at once.. can be quite painful.
we optimized the way we retrieve site settings and configuration, which occurs sometimes hundreds of times per page.
we had some shared lock blocking and other general inefficiencies in our Redis C# library which was causing Redis (network level cache) to be slower and more blocking that it should be. This has been rewritten to be faster and block far less.
all our database calls were not quite going through the same central hub (almost, not quite) causing too many database connections in some circumstances. This has been correctly centralized now.
lots of general profiling with .NET profiling tools to identify places where we had gotten sloppy and were doing something inefficient.
we are restructuring and reorganizing our JavaScript to make the delineation between "only anonymous users need this" and "registered users need this" clear, so as to reduce the footprint of our site to an absolute minimum for anonymous users. This also significantly improves page load time (perceived and actual) for registered users as well.
To me, disclosing the technical details about how you run and optimize your sites is one of the greatest services to the community that you guys are doing. Please never ever give it up, the totality of all these contributions already is a treasure trove for everyone interested in running a high-traffic site. (That said, this should probably go on the serverfault blog, no? ... or webmasters?)
May I suggest one more improvement? Maybe shrinking whitespace via each html page would help with page load times and network performance. View the Source on your html page. Compressing and removing ALL white space outside the actual content of the html would help increase network performance.
@Scott: I don't expect that would improve performance significantly, and since SE started as (AFAIK) a programmer help site, it makes sense to have the HTML be programmer friendly.
Some congratulations are mandatory here, I always know when my connection goes off or is being sloppy: I just type "stackoverflow.com" and see how quick the answer is :)
yours is caused by bits pouring out of broken cables (bitstream liquifaction - awesome duuuuude!!). For the rest of us it is just crap peering/interconnections by TelstraClear.
People in New Zealand don't need the internet because they've got all that outdoors to play in. If you're in the country that invented bungie jumping and zorbing, what do you need with a computer? :)
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
eeeek
tag. :Palways-friday-in-iceland
synonym get deleted?‽
? Where did you find it?