in Uncategorized

Your MVC may be Slowing Down Your Site

One of most common design patterns used on the Web is the model-view-controller. Though some variations of this pattern exist, the basic idea is simple – a controller parses and processes the incoming HTTP request, thinks for a while, and then writes a view as HTTP response.

The point of this post is not to blame MVC, but to point out that implementations in web frameworks may be leading to higher time to first byte times.

But did you know that, this style, as commonly implemented, may be slowing down your site? See the waterfall charts below for some of the Alexa's top 500 sites in US, captured using webpagetest over the DSL network profile with Firefox.

When you look from the network perspective, all these charts share a common pattern – deafening silence, followed by a log jam.

The network is silent when the server is thinking (the green area). As soon as response starts to trickle down (the blue area), the browser starts new network activity and immediately gets into a log jam mode. In this mode, the browser is busy making DNS look ups, TCP handshakes, followed by several HTTP requests over a limited number of connections.

From a user experience point of view, this is bad as it leads to a rapid backlog of HTTP requests. As the number of connections is limited, it takes a while for this log jam to clear up which increases the overall page latency. A protocol like SPDY can deal with the log jam better, but reducing the jam is better for the user.

The problem here is not with MVC per se, but how it is commonly implemented. Most often, the thinking part consists of talking to back-end systems and/or some computation completely blocking response generation. Even in implementations that do some of this thinking asynchronously, view rendering ofter starts after the thinking part is done. This contributes to higher "time to first byte" times and the subsequent log jam.

Below is a waterfall chart of a site that minimizes this log jam.

In this case, the server is starting HTML delivery as soon possible so that the browser can start to download some of those resources sooner. The HTML delivery continues even after some of the subsequent resources complete. This is possible by interleaving HTML delivery with backend work and stream chunks of response as they become ready.

Though such sooner delivery does not completely avoid the log jam, it does help ease it.

If you do MVC, don’t forget to think from the network point of view.

Update: See the Hacker News thread for more comments: http://news.ycombinator.com/item?id=4194500

Write a Comment

Comment

39 Comments

  1. It is not MVC which slows down your site. It is a large number of resources you may have in your page, like js, css or images. The solution for this problem is to minimize number of requests using various techniques like: merge js, merge css, use sprites or cssDataUri for encoding images into css files.

    • These are orthogonal issues. Longer TTFB is a consequence of how the server is implemented. Most sites already do the things you mention but still suffer from longer TTFB and the consequential log jam.

      • The same here, the TTFB is not related to MVC. If your problem is on the server-side, you can split the business logic in smaller chunks and run it in parallel. The title is at least misleading ….

  2. This is because most web applications require heavy I/O processing. Most websites TTFB time is proportional to how fast your disk is (not your CPU/RAM). Faster I/O (faster hard-drive such as RAID-10 on SSD) will reduce your TTFB dramatically.

  3. This is simply a criticism of how server-side applications operate, and it has nothing whatsoever to do with MVC.

    What you’re suggesting is that people stream more content in a staggered fashion so it reaches the client faster and not all at once. Interesting idea, but say what you mean, not some drivel about a concept as generic as MVC being at fault. Nonsense.

      • Right, to quote from the title, opening sentence, and various other paragraphs:

        > MVC may be Slowing Down Your Site

        > One of most common design patterns used on the Web is the model-view-controller. … But did you know that, this style, as commonly implemented, may be slowing down your site?

        > If you do MVC, don’t forget to think from the network point of view.

        Overwhelmingly misleading, in a similar fashion to news stories on scientific articles. Eg: “Eating chicken may be killing you,” followed by an article that talks about eating *fried* chicken in mass quantities. Not the same issue.

  4. I feel that the argument that MVC is slowing your website isn’t accurate. It’s more a problem of a controller or any code that has data it needs to fetch before it can render output to the client. While your proclaiming that MVC may be slowing down your site your negating this argument in the latter part of your post, which makes me a bit confused.
    The log jam issue you mention can be alleviated by minimizing the amount of request for external resources, use of CDN’s and so forth. Also this is not a MVC related issue either.

    • > “The log jam issue you mention can be alleviated by minimizing the amount of request for external resources, use of CDN’s and so forth. Also this is not a MVC related issue either.”

      Interesting point, but in reality, due to limited no connections, requests do get backed up in the browser itself. In the charts above (you can try more to confirm) most of the subsequent resources are coming from the CDN.

  5. Awesome. I have not tested, but I kind of expected this. I think MVC was originally invented for good maintenance, but not for good performance. :)

  6. IMHO from a user experience point of view what matters is when can a user start interacting with the UI. So won’t the final loading time be the same

  7. The main issue I see is that you cannot start rendering back a response until you know the HTTP status (200, 403, 404) and in order to figure that one out you need to burn pretty much the most of your controller ‘thinking’ time.