Optimising HMVC Web Applications for Performance
In an earlier article written for techPortal, Scaling Web Applications With HMVC, the Hierarchical-Model-View-Controller architecture was explored. Using an example web application called Gazouillement and the Kohana Framework, the article investigated how structuring code using an HMVC methodology can help overcome some common scalability challenges in complex software architectures. The article concluded by demonstrating the relative simplicity of horizontally scaling the HMVC Gazouillement example application, after analysis of the execution bottlenecks.
The previous article was intended to be a reintroduction to HMVC for the web application era. HMVC is not a new concept: it was originally referenced in a Java World article over ten years ago and based on an idea that dates back forty years. Todays rise in notoriety of HMVC might be due to the popularity it is enjoying in modern frameworks. Or it could be that the similarity in size and scope of modern web applications to their desktop cousins has given developers reason to revisit the HMVC architecture. Given the present interest in HMVC, this is a great time to explore the subject further and answer a few of the questions arising from the previous article.
Hierarchical-MVC has been shown to make large web applications easier to scale out, but there is a price to pay- namely overall performance. This article will investigate ways of improving performance within HMVC web applications using asynchronous processing and some good old caching techniques. Predominantly this article will use examples written for the Kohana Framework; however all the concepts portrayed here could apply to any framework or web application.
What's wrong with Hierarchical-MVC?
So far there has been nothing but praise for Hierarchical-MVC, but like most things it is far from being a silver bullet. As with everything in life, nothing comes for free. In this case, a clean logical structure applied to code costs in overall performance.
Lets consider the following code that could be found in a controller to load a user from a resource. Example A uses a direct database data provider, whereas Example B uses the HMVC method to get the same resource.// Example A - Load user model directly in traditional style $user_a = new User('email@example.com') -load($db); A // Example B - Load user model using HMVC style $user_b = Request::factory('firstname.lastname@example.org') -method('GET') -header('Accept', 'application/json') -execute($json_decoder);
$user_a and $user_b contain the same data representation. But with all things being equal, the data in $user_a will be loaded and available much faster than the $user_b model. $user_a is using an injected database resource to load its contents, whereas $user_b is creating a request to an internal MVC triad for its data. Database connections are not
Truncated by Planet PHP, read more at the original (another 83586 bytes)