Rudi Benkovič rudib@whiletrue.com
While True, d.o.o.
www.whiletrue.com

A very simple read-only MVC application.

As per ASP.NET MVC.NET’s guidelines:
 ASP.NET MVC 1.0
 Also MVCFutures – official addons for MVC
LINQ-SQL

IIS7

SQL Server


Wow! IntelliSense!

We’re testing response time, not overall
throughput – just one concurrent connection.

IIS7 ApacheBench
ab.exe –n 100 –c 1 http://.../

Response time Requests / second
500ms 2
250ms 4
100ms 10
50ms 20
25ms 40
15ms 66.6
10ms 100
5ms 200
Place your bets!

(Core2 Duo 2.5GHz, 4GB RAM, Win2008 64bit) 8 requests / second
Oops

A better “user experience”: responsive web application
1.
System can respond to many concurrent
2.
requests
We can do more things in a single requests:
3.
richer web applications

JetBrains dotTrace

 Run as Administrator
 IIS worker process: set CPU affinity to a single
CPU

Expression links

Route itself
Name Default values

Expression link

Html.BuildUrlFromExpression<AccountController>(a => a.UserHome(username))
Name the action and the controller

Url.Action(\"UserHome\", \"Account\", new {username = username})
Name the route

Url.RouteUrl(\"User\", new { username = \"joeuser\" })
Brute force

string.Format(\"User/{0}\", Url.Encode(username))

Time [ms for 200 links]
390,0 (!)
20
18
16
13.6
14
12
10
7.2
8
6
4
2
0
Expression Action Route

Why are variables that much slower?

Different code path for non-constants. We have to compile (!) the expression!

Simple syntax. But, how do we read data from such
objects?

Reading data from an anonymous class into
RouteValueData (required). Overhead!

Passing multiple parameters can yield a
significant overhead.

Pass data in a RouteValueDictionary!
Syntax isn’t nearly as nice, but is it worth it?

Time for 200 links [ms]
390,0 (!)
20
18
16
13.6
14
12 9.8
10
7.2
8
6 3.8
4
2
0
Expression ction, anonymous Action, dictionary anonymous object dictionary
A class Route, Route,
As speed increases, so does the syntax and maintenance overhead!

Results:
8 requests / second => 25.5 requests / second
Replace anonymous classes with
RouteValueDictionaries:
25.5 requests / second => 27 requests / second

Each LINQ-SQL
query calls
BuildQuery, which
seems to be time
consuming. Why?

Deffered evaluation

The expression gets transformed into SQL only
when we call such a method that demands data for
its work.
These transformations get cached inside the

DBContext. Web applications can’t share
contexts, so there is no effective caching
getting done.

ToList() triggers the compilation of the query

Compile the expression tree into an SQL

query and mapping methods. Store them as a
function that is thread-safe and accepts a
DBContext and query parameters.

Non-compiled LINQ-SQL query.

Static delegate that
stores the compiled
query
It’s simple, really...
Static DLO
Return value
The original query

Usage: call the static function with the

current DBContext

Additional feature: join more queries into one!

A lot of overhead source code. Uncompiled

LINQ-SQL queries are terse, these just aren’t.
Black magic – the original query won’t always

work as-is. Exceptions from within LINQ-SQL
that you can’t really debug.
A compiled query has to always be called with

the same instance of
DataLoadOptions, otherwise it fails!

Simple generic, lambda syntax for queries

parameters: only for up to three parameters!
Otherwise you’ll need to declare a class for
parameters.

Results:
25 requests / second => 52 requests / second
The difference isn’t as big as in real-world
projects: we don’t have a lot of parameters
for queries and the expressions are simple.

RenderPartial gets called 41 times from the Index
view! Let’s optimize that by passing the
enumeration to the view itself.
Somewhat defeats partial view’s intended usage, but...

41 calls to RenderPartial => three calls.
Results:
52 requests / second => 61.5 requests / second

URLs for MVC applications are typically

static: they don’t change depending on the
user/session/request.
Let’s cache them!

We wrote our own caching API that uses

ASP.NET’s builtin memory cache.

Extend ASP.NET MVC’s UrlHelper into UrlHelperCached, add
new cached methods for Action links.
Join all of data for a single link (action, controller, data) into a
string and use that as the cache key.

UrlHelper doesn’t implement an interface and it’s methods
aren’t virtual. We’ll add our own UrlHelperCached as a new
UrlCached property by extending MVC’s classes:
MasterPage, ViewPage, ViewUserControl.

Usage: inherit our View class in view’s definition
and replace Url with UrlCached. That’s all!

Results:
61.5 requests / second => 76 requests / second
Real-world: as routing table gets longer and
more parameters get passed around, the
difference is even greater!

We can cache site statistics.
Here’s our little caching API that uses lambda
syntax for cached values. A lot less code!

Cache stats and top voted news of all time:
76 requests/ second => 153 requests/ second.
Let’s also cache the main news display:
153 requests/ second => 400 requests / second.
Caching all DB data foregoes any SQL-LINQ or SQL
connection initialization. Even less overhead with
much faster response times.

Core2 Duo 2.53GHz, 4GB RAM, IIS7 Optimization only Data caching
450 400
Requests per second
400
350
300
250
200 153
150
76
61.5
100 52
27
25.5
50 8
0

Each of these optimization methods is in
production: fast URL generation, compiled
queries, URL caching, data caching.
The first alpha version
without any optimizations
ran at ~3 requests / second.
Today, the index page can
withstand ~800
requests/second on a
development webserver with
real world DB data. HTTP
concurrency = 8.

After a few uncomfortable moments of silence...
Questions?

Ideas for ASP.NET MVC developers:

 Smarter view compiling. Let’s inline partial code
for views. Or let’s write a new view engine.
 RenderPartials() method that accepts an
enumeration and can also use a spacer view – like
RoR.
 Builtin URL caching – why not? Or at least make
interfaces for HTML and URL helpers.

Thanks to Simone Chiaretta for discovering a gross oversight
on my part: I’ve done my benchmarks with ASP’s debug
mode turned on. With regards to ASP.NET MVC 1.0, this
disables its view engine’s internal cache for resolved paths to
views. This makes specifying full paths to view irrelevant as
far as performance is considered.
So, the following change won’t yield any performance yield
with the debug attribute set to false
(Web.config, compilation section).

All of the benchmarks have been re-run with debug turned
off, the change before any optimizations have taken
place is significant (6 req/s to 8 req/s). Any other
changes to the performance due to the release mode
other than view path resolving were basically non-
existing or within the margin of error.
You can read Simone’s post at
http://codeclimber.net.nz/archive/2009/04/22/how-to-improve-
htmlhelper.renderpartial-performances-donrsquot-run-in-debug-mode.aspx
And, of course, run your production websites in
release mode. :)