It seems I was wrong all the time! Lot of partial views WILL NOT slow down page rendering!

Profiling tools you use can slow down the application! After I disabled Glimpse, time-to-first-byte in Chrome was the same, in optimized version with 10 partial views, as in version with 182 partial views! It seems Glimpse injects some code into MVC execution pipeline to measure timings and who-knows-what, which introduces around 5-10ms per view call.

There’s no simple and quick “turbo button” for you application, unfortunatelySad smile But you need to learn how to use development tools, and how to read the results. The devil is in details.


The old blog post, if you’re interested:

Here goes a quick advice how to speed up performance of your website, at least Time-to-first-byte!

I had a performance problem with one e-commerce web site, where visitor needed to wait at least 5 seconds to see the web page. There were some changes with database server, so my first assumption was the speed of new server. 

But to verify that, I had to profile page rendering pipeline. The easiest way is installation of Glimpse plugin, with EF add-on. After doing that, to my surprise, I saw database takes less than 10ms to return the results, so the devil has to be somewhere else! Going through glimpse Tab, I noticed this horror (here's just the part that fitted into my screen):


There were than 180 partial view calls from main page (remember, it's an e-commerce web site, each partial view renders one product. There are 9 categories with 9 products each rendered on the home page, and each product partial view calls another partial view to show some additional information – total of 182 views rendered)! And that took at least 80% of the whole rendering time for that page!

Now when I knew what's the problem, solution was easy, refactor of few Razor views, and rendering time went from 5-10 secs to under 1 second (on my local box went from 2+ secs to around 400ms, on remote VM from 5-10 secs to less than 1 sec). All done by simply reducing number of partial view calls from 180 to 10.

Side note; it makes code uglier, since I don’t have nice encapsulation of each partial view, than can be called from different places, but rather duplicated code in few Razor files. But the business value here is obvious! From development perspective, each duplicated content is well marked with code comments, so when someone modifies the code in one place,  he/she will know that code needs to be copied to another location.  


Nice, small and quick optimisation! MVC version I’m using is 5.2.3, but in v6 we can expect some major performance improvements of Razor view engine, so can’t wait to revisit this little test in about half year!

Moral point of the story; measure first, then fix! And definitely use Glimpse if doing any ASP.NET MVC work, it can save you hours of investigation!


It usually goes like this:

  • Lets hack a prototype or proof of concept
  • Deploy to production
  • The hell, people are visiting my web site and I didn't add any application logging!

Happens to me all the time. I'm adding some logging framework when it's too late, users complained, site went down, don't even know what happened! Not really sure why is that, but my theory is that most popular framework requires XML configuration in web/app config, and it's often very difficult to find all the config options, so I tend to leave "logging feature" for the end. I also hate XML-based configuration for those types of stuff. Some logging framework supports code-based configuration, like Serilog.

Some options for logging are:

  • Elmah - really easy to add, but logs only exception
  • Nlog or Log4net - really similar frameworks, more of a personal preference which one to use
  • Serilog - interesting new framework, easy to use code based configuration yay!
  • AppInsight, New Relic, Splunk - much bigger and complex solutions and services, can be plugged in to some other framework like nlog or serilog, as a storage of events. They offer whole set of analytics, diagnostics and reporting tools. Really useful feature of those are ability to log server events - number of web request, memory consumptions, database requests and timings, etc

No matter what framework you pick, it's important to set API over logging right, and then implement it in the framework of your choice. In one of my recent projects, we created logging semantics in two dimensions: level and type:

  • Level is standard logging level like verbose, debug, info, error, etc
  • Type is something that describes an event, provides better semantics about the event, and can be, for example:
    • Diagnostics - system and application related events
    • Operations - business related events
    • Performance - benchmarks

So every log event needs to describe also those two dimensions; level and type. Translating that to an interface, it can look like:

Some logging frameworks and services like Serilog and Splunk supports storing of structured objects (DTOs) into a store, which are then later available for querying. That can be really useful feature, since those objects are stored in their "native" structure (JSON) inside NoSQL store, they are not flattened into one string, all information are preserved (think of queue messages, commands, requests, that can be stored and later inspected in case of a problem).

To support sending of objects API can be expanded little bit:

void Log(LogLevel level, LogType type, string message, params object[]  data)

There's one more neat trick that can be used to make API semantics little bit better and easier to use; we can add extension methods to for ILoggger:

And so on. You get the point:)

With  those extension methods, usage can look like this:

which will result in log entries that can look like:

14/10/2015 7:00:00 [Info] [Operation] Trying to pay the order { OrderId:1, Prop:1, Prop2:2, …}
14/10/2015 7:00:01 [Error] [Operation] Error processing payment request
  full stack trace of exception…
14/10/2015 7:00:10 [Debug] [Performance] Payment service executed in 1234ms

with log entries like this, it much easier to get the context of the entry. We can search for all Performance entries for example, and find bottlenecks, or get only business related (Operation) entries and filter out technical one.



Short intro: my new year resolution, decided in April, is that I will write weekly blog posts. Short, concise, something I worked on last week or whatever…  so here is the first one!

This was a small problem I had in the office, one co-worker created two apps, of which one is WebAPI on self-hosted OWIN, other one is a win service. Exposing objects from WebAPI and reading them through HttpClient caused some problems when we refactored them, introduced polymorphism in this case.

Issues were:

  • JsonConvert couldn’t de-serialise received string, throwing this exception:
    An unhandled exception of type 'Newtonsoft.Json.JsonSerializationException' occurred in Newtonsoft.Json.dll

    Additional information: Could not create an instance of type JsonTypeNameHandling.Vehicle. Type is an interface or abstract class and cannot be instantiated

  • We wanted to inspect what WebApi is returning, but XML serializer was kicking in
  • We wanted to see full error details

This is common problem with WebApi, since (I guess) default Json settings are not configured to send object type information (recognized by “$type” in Json). Configuration needed for those issues:

  • both sides (server and client) needs Json.net settings to use type names:
    Client side (using HttpClient):
    JsonConvert.DeserializeObject<MyType>(payload, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Auto })
    Server side (WebApi):
    configuration.Formatters.JsonFormatter.SerializerSettings.TypeNameHandling = TypeNameHandling.Auto;
  • Serve Json when invoking WebApi with browser:
    configuration.Formatters.JsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));
  • Show error information:
    configuration.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;

The whole example, a small app that creates web server (with OWIN and HttpListener) and calls itself:

Solution can be downloaded from Github