Changing gears
Backed up from a local Blogger export (114645939913203361/114645939913203361.html) on 2026-01-01.
Now that work is settling down a bit I can get back into a better groove. I’ve been in pure execution mode for the past two months which can really get a bit tiring but it’s always rewarding to ship a product. The v1 launch was a lot more exciting and scary but also more grueling. I didn’t keep absolute track but I may have spent 4 months doing performance tuning on that release. A lot of hard problems have already been solved and some problems are just known so we have to work with what we have.
We really had some suprises this time around though. I don’t think that anyone was ready for the fact that using an async model in ASP.NET would actually hurt us on overall performance, ASP.NET 1.1 seems to have a peak throughput of 1k req/sec on the machines that we use as well as some really nasty thread contention problems. With IAsyncHttpRequest we ended up using a maxio/maxworker setting of 5 which allows us to saturate at around 600 req/sec. If you leave the setting at the default of 20 or use 100 as we were using for the old sync model you quickly land in thread contention land, population 1 very unhappy cpu.
So anyways, back to doing research, coding and thinking. I will be doing a lot of reading on SQL performance tuning but if there’s one thing that I’ve learned through the years of working on large servers: think about and do the hard stuff first. The best optimizations will be made in the overall application design. It must account for the difficult performance problems because it’s the one part that you will have the most trouble changing later on if it’s wrong.
Finally got a solid SVN setup at home.. I had been wondering for so long why I couldn’t reach my wired machines from the wireless network but the converse worked just fine. I was thinking I had problems with my routing tables etc until I got the idea to look at my firewall settings. Ding! We have a winner. I feel like an idiot :P