The talk was first given in Slovene on 15.4.2009 at a local Microsoft developers user group, SLODUG.

Additional notes:

We cannot assume that only implementing database caching will lead to a significant performance gain before optimizing any other aspects of page’s rendering. Here’s a few more metrics for the DUGG application:

• First run, as in the slides, no optimizations whatsoever: 5.9 requests / second
• Added: Compiled SQL-LINQ queries: 6.88 requests / second
• Added: Fully cached SQL-LINQ queries: 7.43 requests / second/
• Removed: expression links, replaced with route and actions links. Also fixed path to partials with the full path: 112 requests/second

That still leaves room for the treble performance improvement with URL caching and views that render enumerations.

It’s one of the general rules of optimizing software that speedups in one part of the application will have a lot of consequences elsewhere which you can’t really predict. Test, measure, profile, optimize a single hotspot, repeat!

Errata (23.4.2009)

Thanks to Simone Chiaretta’s analysis of my results, he’s nailed it that I forgot to disable the debug mode for benchmarks (oops!). This disables ASP.NET MVC’s internal cache for paths to views, rendering my part of optimization notes to replace paths to views with full paths irrelevant. I’ve re-run all of the benchmarks, removed two slides and added an errata to the end of the slides.

It would be nice if I can be proven wrong on other points as well.