
MVC may be Slowing Down Your Site - balakk
http://www.subbu.org/blog/2012/07/mvc-may-be-slowing-down-your-site
======
Produce
Oh my god, really? Doing server side processing means that nothing is being
sent until said processing is over? What have I been doing with my life?!

Seriously, stop posting and upvoting these stupid as hell blog posts, install
Varnish or load your content with AJAX. And _most_ importantly, don't put your
real name on posts like these.

~~~
calinet6
Thank you for being the hero that this thread needs. You're absolutely right,
and your tone and bluntness is completely appropriate for the quality of this
post.

------
shanemhansen
I disagree with the general tone here. The fact is that relatively
unsophisticated frameworks often perform better from a UX point of view
because of this very reason.

I know I'm over-generalizing here, but most PHP apps can print a the website's
headers and navigation and send those to the browser before it starts doing
the heavy lifting. The reason? Basically because they are just a smart
template, and the logic is in the view.

Java JSP's are actually the same. Very often you can see a jsp powered site
print the website headers and CSS so that the browser can be rendering while
the server is still working.

The problem with most MVC frameworks is that their interface looks like
HTTPResponse process(HTTPRequest), which doesn't imply but pretty strongly
suggests that the server isn't going to send any data back until the request
is finished processing. Generators provide an API that theoretically gets
around this limitation, but in reality would require massive amounts of coding
in order to make all the iterators involved lazy.

So using some dumb, non mvc frameworks, it's easy to get a shorter time-to-
first-byte. With a fancy MVC framework, it's pretty difficult and involves
lots of lazy loading (to delay the processing associated with database
requests).

So yes, MVC as implemented by most of the web, might be slowing down your
site, and despite the relative sophistication of the HN crowd, it's not a
problem that most front-end devs have on their radar.

~~~
sallamar
Well said. Pages that start with the view like PHP and JSP fare better than
most dumb MVC frameworks.

------
gsoltis
This doesn't seem to have much to do with MVC. Assuming that the beginning of
the requested page can be returned while more processing is ongoing, it seems
like a controller method would be a good place to do this.

It might be interesting to try something like this with a generator, so that
"for response in process_request(request): send_response_to_client(response)"
would work.

------
arthurschreiber
As others have already pointed out, that has nothing to do with MVC, but is
more a result of how template engines usually work.

E.g. in Rails, by default, due to the fact that you can have views provide
content for your layout (using content_for), it has not been possible to start
sending your rendered HTML before the rendering was completely finished.

There is an experimental Fiber based solution in Rails Core, that shipped with
3.2, that kind of fixes that issue, but only to a certain degree (see
[http://api.rubyonrails.org/classes/ActionController/Streamin...](http://api.rubyonrails.org/classes/ActionController/Streaming.html)).

------
adrianbravo
"The problem here is not with MVC per se, but how it is commonly implemented."

So why give it a linkbait-style title?

------
jlarocco
> "The problem here is not with MVC per se..."

Even the article admits this isn't necessarily an MVC problem.

------
radagaisus
This has nothing to do with MVC.

------
anselmoars
This has nothing to do with MVC, ABC, <put your architecture here>. You should
eliminate the initial browser blank state, optimise the TTFB and your start
render time, number of resources <23+4 Steve Sauders optimisation techniques>.
Twitter found Time To First Tweet as an important KPI, and it caused them to
build a mixed deliver architecture (server-side and client-side,
[http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html))

------
postfuturist
Hm, what if there is an error in processing and you've already sent the
"HTTP/1.1 200 OK" and started streaming output? You're better off utilizing
caching and other optimization based on profiling.

------
tangue
By definition a browser can't see what's happening on the server side. There's
a lot of things that can block loading (io, database, network ...). Pointing
the finger at an architectural pattern using data collected via a browser
extension is pure speculation.

~~~
sallamar
What you can infer from such testing is that the server is not writing any
response for a while, and then quickly writing all the response. There could
be two reasons - the server may be busy doing some blocking activity, or the
server or some intermediary is buffering all the response in memory and
emitting it when the complete response is available. Experience tells me that
it is usually the former. I'm the author of this post.

------
jaequery
most developers don't understand the concept of I/O. The I/O speed is really
important in terms of TTFB. Most websites are hosted on SATA drives which have
poor IO speed. Even if they are on RAID-10. The speed of CPU doesn't really
matter here, unless your app does heavy CPU processing. To speed up TTFB, only
thing you can do is to cache/cache/cache, and possibly having a varnish in
front of your web apps. Also you'll see substantial boost in TTFB times if you
switch over to something like RAID-10 SAS, and even more so if you switch to
the newer drives like the SSD. I've seen Magento stores go from several
seconds per load to almost varnish-cache level when placed on PCI-Express
SSDs.

------
manuscreationis
This has nothi...

Oh, everyone else already covered it.

