The first workshop on Monday morning was called Death of a Web Server: A Crisis in Caching. The presentation itself is downloadable from that link, so follow along! I took a lot of notes though because much of this was coding and testing, not pure presentation. (As with all these session writeups, the presenter or other attendees are welcome to chime in and correct me!) I will italicize my thoughts to differentiate them from the presenter’s.
It was given by Richard Campbell from Strangeloop Networks, which makes a hardware device that sits in front of and accelerates .NET sites.
Richard started by outing himself as a Microsoft guy. He asks, “Who’s developing on the Microsoft stack?” Only one hand goes up out of the hundreds of people in the room. “Well, this whole demo is in MS, so strap in.” Grumbling begins to either side of me. I think that in the end, the talk has takeaway points useful to anyone, not just .NET folks, but it is a little off-putting to many.
“Scaling is about operations and development working hand in hand.” We’ll hear this same refrain later from other folks, especially Facebook and Flickr. If only developers weren’t all dirty hippies… 🙂
He has a hardware setup with a batch of cute lil’ AOpen boxes. He has a four server farm in a rolly suitcase. He starts up a load test machine, a web server, and a database; all IIS7, Visual Studio 2008.
We start with a MS reference app, a car classifieds site. When you jack up the data set to about 10k rows – the developer says “it works fine on my machine.” However, once you deploy it, not so much.
He makes a load test using MS Visual Studio 2008. Really? Yep – you can record and playback. That’s a nice “for free” feature. And it’s pretty nice, not super basic; it can simulate browsers and connection speeds. He likes to run two kinds of load tests,and neither should be short.
- Step load for 3-4 hrs to test to failure
- Soak test for 24 hrs to hunt for memory leaks
What does IIS have for built-in instrumentation? Perfmon. We also get the full perfmon experience, where every time he restarts the test he has to remove and readd some metrics to get them to collect. What metrics are the most important?
- Requests/sec (ASP.NET applications) – your main metric of how much you’re serving
- Reqeusts queued (ASP.NET) – goes up when out of threads or garbage collecting
- %processor time – to keep an eye on
- #bytes in all heaps (.NET CLR memory) – also to keep an eye on
So we see pages served going down to 12/sec at 200 users in the step load, but the web server’s fine – the bottleneck is the db. But “fix the db” is often not feasible. We run ANTS to find the slow queries, and narrow it to one stored proc. But we assume we can’t do anything about it. So let’s look at caching.
You can cache in your code – he shows us, using _cachelockObject/HttpContext.Current.Cache.Get, a built in .NET cache class.
Say you have a 5s initial load but then caching makes subsequent hits fast. But multiple first hits contend with each other, so you have to add cache locking. There’s subtle ways to do that right vs wrong. A common best practice patter he shows is check, lock, check.
We run the load test again. “If you do not see benefit of a change you make, TAKE THE CODE BACK OUT,” he notes. Also, the harder part is the next steps, deciding how long to cache for, when to clear it. And that’s hard and error-prone; content change based, time based…
Now we are able to get the app up to 700 users, 300 req/sec, and the web server CPU is almost pegged but not quite (prolly out of load test capacity). Half second page response time. Nice! But it turns out that users don’t use this the way the load test does and they still say it’s slow. What’s wrong? We built code to the test. Users are doing various things, not the one single (and easily cacheable) operation our test does.
You can take logs and run them through webtrace to generate sessions/scenarios. But there’s not quite enough info in the logs to reproduce the hits. You have to craft the requests more after that.
Now we make a load test with variety of different data (data driven load test w/parameter variation), running the same kinds of searches customers are. Whoops, suddenly the web server cpu is low and we see steady queued requests. 200 req/sec. Give it some time – caches build up for 45 mins, heap memory grows till it gets garbage collected.
As a side note, he says “We love Dell 1950s, and one of those should do 50-100 req per sec.”
How much memory “should” an app server consume for .NET? Well, out of the gate, 4 GB RAM really = 3.3, then Windows and IIS want some… In the end you’re left with less than 1 GB of usable heap on a 32-bit box. Once you get to a certain level (about 800 MB), garbage collection panics. You can set stuff to disposable in a crisis but that still generates problems when your cache suddenly flushes.
- 64 bit OS w/4 GB yields 1.3 GB usable heap
- 64 bit OS w/8 GB, app in 32-bit mode yields 4 GB usable heap (best case)
So now what? Instrumentation; we need more visibility. He adds a Dictionary object to log how many times a given cache object gets used. Just increment a counter on the key. You can then log it, make a Web page to dump the dict on demand, etc. These all affect performance however.
They had a problem with an app w/intermittent deadlocks, and turned on profiling – then there were no deadlocks because of observer effect. “Don’t turn it off!” They altered the order of some things to change timing.
We run the instrumented version, and check stats to ensure that there’s no major change from the instrumentation itself. Looking at cache page – the app is caching a lot o fcontent that’s not getting reused ever. There are enough unique searches that they’re messing with the cache. Looking into the logs and content items to determine why this is, there’s an advanced search that sets different price ranges etc. You can do logic to try to exclude “uncachable” items from the cache. This removes memory waste but doesn’t make the app any faster.
We try a new cache approach. .NET caching has various options – duration and priority. Short duration caching can be a good approach. You get the majority of the benefit – even 30s of caching for something getting hit several times a second is nice. So we switch from 90 minute to 30 second cache expiry to get better (more controlled) memory consumption. This is with a “flat” time window – now, how about a sliding window that resets each time the content is hit? Well, you get longer caching but then you get the “content changed” invalidation issue.
He asks a Microsoft code-stunned room about what stacks they do use instead of .NET, if there’s similar stuff there… Speaking for ourselves, I know our programmers have custom implemented a cache like this in Java, and we also are looking at “front side” proxy caching.
Anyway, we still have our performance problem in the sample app. Adding another Web server won’t help, as the bottleneck is still the db. Often our fixes create new other problems (like caching vs memory). And here we end – a little anticlimactically.
Class questions/comments:
What about multiserver caching? So far this is read-only, and not synced across servers. The default .NET cache is not all that smart. MS is working on a new library called, ironically, “velocity” that looks a lot like memcached and will do cross-server caching.
What about read/write caching? You can do asynchronous cache swapping for some things but it’s memory intensive. Read-write caches are rarer- Oracle/Tangosol Coherence and Terracotta are the big boys there.
Root speed – At some point you also have to address the core query, it can’t take 10 seconds or even caching cant’ save you. Prepopulating the cache can help but you have to remember invalidations, cache clearing events, etc.
Four step APM process:
- Diagnosis is most challenging part of performance optimization
- Use facts – instrument your application to know exactly what’s up
- Theorize probable cause then prove it
- Consider a variety of solutions
Peco has a bigger twelve-step more detailed APM process he should post about here sometime.
Another side note, sticky sessions suck… Try not to use them ever.
What tools do people use?
- Hand written log replayers
- Spirent avalanche
- wcat (MS tool, free)
I note that we use LoadRunner and a custom log replayer. Sounds like everyone has to make custom log replayers, which is stupid, we’ve been telling every one of our suppliers in at all related fields to build one. One guy records with a proxy then replays with ec2 instances and a tool called “siege” (by Joe Dog). There’s more discussion on this point – everyone agrees we need someone to make this damn product.
“What about Ajax?” Well, MS has a “fake” ajax that really does it all server side. It makes for horrid performance. Don’t use that. Real ajax keeps the user entertained but the server does more work overall.
An ending quip repeating an earlier point – you should not be proud of 5 req/sec – 50-100 should be possible with a dynamic application.
And that’s the workshop. A little microsofty but had some decent takeaways I thought.
