I'm currently building a web application using Zend framework 1.11.11 and Doctrine 2.2. I searched a lot for the best ways and hacks to optimize the frameworks used.
During my search for Zend framework optimization I stumbled upon this post:
Optimising the Zend Framework
What was interesting about it is that it mentioned few optimization techniques that emerged from the usage of the framework itself and wasn't covered in the manual itself such as:
disable viewRenderer and take care of view rendering yourself.
Now I'm looking for similar techniques that could be applied to Doctrine 2 other than the ones mentioned here in the manual.
Note
I know many will mention profiling the queries, caching and finding the bottle neck of the app, but that's not um looking for :) I am looking for practical enhancements discovered during Doctrine 2 usage.
Thanks ;)
Well, optimizing and hacking Doctrine 2 will not be an easy task. I can only advise you to follow the official "best practice":
Use Query Cache
Use Metadata Cache
Pre-generate proxies
Avoid listeners (or merge them by event type (flush, update), it will avoid the lookup time and the loop for subscribed events)
Use lazy-loading whenever it is possible
Make sure your relationships or inheritance are not messed up
(Note that I didn't mentioned Result cache which should not be a way to optimize an application)
From my use, the most important part I had to optimize was not Doctrine itself (while there are optimizations to do to the core) but the generated Query, as always, I EXPLAINed the queries and optimized indexes.
Doctrine 2 can be high memory consuming so loading a lot of entities at once may slow down your application, you may find it useful to known about clear(), detach(), iterate() methods.
Despite the fact Doctrine 2 can sometimes be slow, I mostly noticed that I was able to optimize application somewhere else, within the Zend Framework or PHP themselves.
Let's say, Doctrine 2 takes 100ms where Zend Framework takes 300ms for a total of 450ms (I/O stuffs, PHP internal functions, etc..)
If you can divide easily by two the time taken by Zend Framework, optimizing Doctrine 2 to gain like 10% will not increase notably the speed of your application. Think about it twice.
Here are a few tips:
Create your own view instead of using View Helpers (avoid the helper lookup)
Cache your Zend_Config object (really heavy load)
Avoid Regex routes whenever possible (ZF routes are a big bottleneck)
Use a ClassMap autoloader instead of the native Zend_Loader_Autoloader
There are tons of optimization to do, some have a real impact while others don't.
Make sure to find them by profiling your application, an easy and cross-platform is to use webgrind.
Related
I have the same question about my current project.
Project type: Something like shopping cart SDK.
Models: 30+ (with extensions)
Extensions: 15+
Tables: 47
Relations: every model have 3+ relations
The most performance demanding part processing: 300ms
On start, I have 10 models with relations, that's why I choose Laravel as Framework, and I do not think about growing.
Now, I have 40 models with a lot of extensions and Laravel work fine.
My project is growing fast.
Now It's a big SDK with a lot of tables, relations, and extensions.
I need advice from experienced developers.
Do I need to switch Laravel to Symfony, to reduce future problems with
performance?
I would be glad if you can advise me on this.
P.S.: I understand complexity with migration from Laravel to Symfony,
Performance-wise there is no big difference between frameworks. If you are coding right - they are all just the same.
But the problem is in this part "if you are coding right".
You must always think about design, about responsibilities, about service layers, and to be consistent with your approaches.
And for this Symfony is much better. It's just a more convenient framework to go with SOLID. And it makes you think in a right direction.
TL;DR: There is no any reason to change Laravel to Symfony.
Symfony has no layer for models handling. It's ORM library's responsibilities (usually we can use Doctrine in Symfony -- but it's possible to use another ORM libraries for that -- even Eloquent). And also it's not a big deal to use Doctrine for Laravel.
But obviously changing framework won't decrease the number of models -- so 40 models in Laravel still will be 40 models in Symfony. Because of this, there is no any advantage for decreasing of complexity.
Also there is no explicit dependency between framework and performance (generally, the DB is bottle neck).
Despite of opinion that Symfony automatically (and magically) increases programming skills -- it's wrong. So if someone able follow to SOLID principles, able to reduce cyclomatic complexity of the code, able to provide strong cohesion and loose coopling for the classes -- it doesn't sense what exact framework could be used. Actually Symfony doesn't force to use the best practices.
Therefore Symfony provides a lot of excellent components. But most of them can be used easily (and actually used) in Laravel.
Laravel is good for medium websites. For big app i would always use symfony or zend.
Maintaining database views in mysql is sometimes cumbersome. When you change a referred table you have to alter the table and there is no clean way to do that in migrations (DB::unprepared()). I guess using query scopes in models is more maintainable. Isn't it? Does it has negative effect on the performance.
I don't know how big your project is and I don't have many elements to judge this situation perfectly.
However, working with views means depending on the underlying database system. Obviously it has its pros and cons, but I would prefer to decouple my software components.
What if you change, in the future, switching from MySQL to MongoDB?
Maybe, you could use a cache system, like Redis or Memcached (and Laravel already has a ready-to-use service for it).
As I told you before, I am making this suggestion basically because I think about the software scalability and components decoupling.
Here you can learn about the basic use of the Cache Service: http://laravel.com/docs/5.1/cache
Also, if you have some confidence with design patterns, you can implement a really elegant solution using some stacked repositories alongside the decorator pattern.
You can find some interesting articles about the topic here:
http://culttt.com/2014/02/03/laravel-4-cache-service/
http://culttt.com/2014/04/23/decorator-pattern/
Yes, they're about Laravel 4 but the concept can be easily adopted in a Laravel 5.* project.
Hope it was useful!
EDIT: as I told in the following comments, if you don't want to start with something like Redis or Memcached, you can always use the filesystem-based Cache.
We have pretty big application which has about 8 modules (big modules) written using Zend framework 1 and it has been developed for more than 3 years by couple of developers. Also it has a high traffic everyday. We use Amozon s3, Sphinx, Memcache, and some other third party services as well.
Is it a good idea to migrate it to Zend framework 2 ? Because as we went through the doc briefly, it seems Zend framework 2 has been re-written completely. Therefore we think we won't be able to migrate the application easily rather than re-writing the application according to ZF 2.
Valuable ideas would be highly appreciated.
You are correct that ZF2 is a completely different animal. So different, in fact, that there's no one-size-fits-all migration plan/strategy.
However, I recently did a similar migration. It's a fairly complex line-of-business application originally written over approximately 18 months, with a bunch of varied functionality. The main drivers for the decision were the improvements in the module and event systems.
In our case, it turned into a major point release for the product, which ended up including a bunch of UI changes along with all the plumbing.
Assuming you liked ZF1, the good news is that ZF2 is much better framework (as a framework). The ModuleManager, EventManager, Di, and ServiceManager components (and the general MVC-related stuff) are really great, once you grok them. The bad news is that they're a complete departure from ZF1. So you're at the very least signing up to completely overhaul your dispatch and routing, you'll be saying goodbye to Zend_Registry (ServiceManager/ServiceLocator are a huge improvement).
The other bit of good news is that you can almost certainly keep all the old ZF1-type components around for as long as you need them. So if you're relying on Zend_Cache, Zend_Log, Zend_Mail, etc, a little bit of fiddling with autoloader configs should make that possible.
What I'm suggesting is that if you do take the plunge, consider just migrating to ZF2-as-a-framework first, and worry about ZF2-as-a-component-library later.
If you've stuck with the fat-model/skinny-controller paradigm, it's probably feasible to just replace the Controllers, Front-Controller, Zend_Application stuff in a fairly straight-forward way. Once you get that into production, you can then work on removing dependencies on ZF1 components as time permits. In my case, there wasn't much of that, as things were pretty well factored and wrapped (so, for example, moving from Zend_Cache to Zend\Cache was trivial)
Finally, you should know up-front that View-layer stuff (mostly the helper-related stuff) is different too. If you have a bunch of complicated view-related stuff (partials, custom view-helpers, etc) all over the place, you need to anticipate either rewriting them, or finding a way to use the old Zend_View stuff in ZF2 so you can migrate piecemeal. I didn't really deal with this because our interfaces were fairly simple and we took it as an opportunity to overhaul the UI.
Just my $0.02, but I hope it helps.
There is no quick and easy way to migrate because ZF2 is very different from ZF1.
Related: Step by step migration from Zend Framework 1 to 2
As far as I understand, every enabled module in a ZF2 application is loaded for every request (unless one uses optimization methods such as that offered by the zf2-lazy-loading-module module). I've been keeping an eye on modules that get published on modules.zendframework.org and I've come across modules which offer extremely limited functionality, such as the AkrabatFormatUkTelephone module which purpose is to format phone numbers to UK format.
Whilst I understand development should focus on creating single purpose modules that are good at doing one thing (instead of modules which do many things but not in a very good way), I'm thinking if we start using modules which offer such limited functionality as the one mentioned, we will need to combine hundreds of modules in order to build a rich application which could be disastrous for performance. Instead I would expect this sort of functionality to be put in a class (e.g. Zend\I18n?) and loaded on demand which would be more optimized. But knowing Akrabat's reputation I'm thinking I must be missing something, hence my question:
Is the loading of modules such as the one I mentioned significantly worse for performance than loading the same functionality via PHP classes (or is it similar due to the way ZF2 has been designed)? Does anybody have any figures (i.e. is it 5%, 10%, 15% slower) about module vs class loading performance?
Don't take this comment as a final answer, as hopefully someone of the ZF2 devs will shed some more insight to it, but generally only Module.php and usually module.config.php will be actively loaded. Everything else will simply be registered and be called on demand. So as long as your Module.php and module.config.php are not TOO big in filesize, the performance shouldn't be THAT big of an issue
In the case of Akrabats example, all that's happening is, the registry of a new ViewHelper. Nothing else. The same with all other view helpers inside of Zend. Performance won't really matter a lot in these cases.
Personally the Skeleton loaded with 80ms on my Webspace and with BjyAuthorize, ZfcBase, ZfcUser and my own module, the loading time ramped up to 100ms. And this is without any sort of memory caching enabled!
Loading a module is not much more than loading any class, like Sam pointed out.
As long as you don't use anything from your module and do things right, it's just beeing registered.
Now what does "do things right" mean?
Just try to put a big nonsense loop inside your module classes bootstrap() method. You will see that this slows down every request on your application, because the bootstrap method of your module is called on every request and it should be used very carefully, only for light weight tasks. The purposes you usually use the bootstrap() method for, won't even slow down your app for a millisecond, but writing a file to the disk in this method could slow down your app for many seconds in each request.
If your app becomes really heavy, you should use the classmap_autoloader and some caching wherever you can. If you did "things right", you won't have any performance problems, just because you have many modules or many classes in your app. One could say, it's just all about algorithms.
Keep going on using best practices, like the one you mentioned. Usually these aren't the bottlenecks of your application, but your own algorithms and failures are.
edit:
When you're using modules from the community, you should always check them for performance issues. Even a module that seems to be very light could be a bottleneck for your application if it has bad algorithms. But the case that you're loading an additional module is not the point of it.
Good question. I would like to contribute a little bit to the reaction of Sam.
Module performance is not solely the loading of the module (which is, as pointed out quite fast), but also the communication of the modules in-between. So this question might boil down to: how slow/fast is the ServiceLocator and Event-driven system in comparison to traditional non-modulair systems?
I recall that ZF2 was build with performance in mind. For instance, the ServiceLocator registers factories, so that objects can be instantiated on-the-fly. So this requires only a few extra in-memory objects and instantiations, I guess this does not impact the total performance for your application much. The EventManager works in much the same way and I have not seen it being overloaded with registered events, even in large applications.
What might slow down, on the other hand, is the loading of the modules configuration. I figure that using a cache might solve this problem. I'm not sure but maybe Zend Optimizer might do this already.
So, in short, applications should scale pretty wel, provided that modules behave well, and do not over-register events or misuse the ServiceLocator.
From the MVC component's perspective there are no modules at all! There's one big configuration file - a result of merge of every module's configuration. Unless your modules don't have a onBootstrap method or don't do much, module loading is as fast as invoking new Module on every one of them, which is painless and memory inexpensive.
The configuration merge procedure, which I mentioned above, happens only in DEV mode which is enabled by default.
There are number of tricks also to speed up your ZF2 application, like:
Enable merged config cache
Use EdpSuperluminal module
Return the ViewModel objects from actions, not arrays
Explicitly set the template name on the ViewModel
Use template maps instead of template path stack alone
Route order in the config matters! Its a LIFO queue (last in-first out).
Make sure you don't load Console modules in HTTP context.
Let the Composer do the autoloading, not ZF2
... and more. There's a quite good talk by Gary Hockin on the ZF2 app performance.
Authorization modules will surely slow down your app. There are number of things going down under the hood: the identity of the user needs to be fetched (from the database?), user needs to be authenticated agains your rules. Surely you can speed things up by using memcached or such, but this requires to have some knowledge about the lifecycle of the ZF2 application, about the modules you use, etc.
Also there is Zend Framework 3 going to be released soon, some things will go faster, but don't expect much. A lot of overhead is a result of your lack of knowledge about ZF2 - no offense!
I would like to know what would be the best MVC framework that can be used give these parameters
Ability to handle large DB
easy to use and configure
secure(session encryption, etc)
high performance
Available support(community)
ability to handle AJAX would be an added benefit, but not critical
I have been looking all over the web with conflicting results.
Please give your views, Efforts appreciated, thanks!!!
Try Yii Framework. I like the way it designed. And they claim the performance of the framework is outstanding (here is the Yii performance comparison to other PHP frameworks).
If you want to use framework for highloaded website, you can go with any framework you prefer. The bottleneck in highloaded applications is usually a database, so you will have to use different kind of caching mechanisms. Yii supports different kind of caches
To optimize complex SQL queries in Yii, don't use it's ActiveRecord, but use DAO instead.
There is no obvious answer though.
What about Simple PHP Framework?
http://clickontyler.com/simple-php-framework/