Recently I've discovered that Laravel 4 is including all the controllers on each request regardless if it needs it or not, even though Composer has the whole controller architecture mapped in its autoload. I'm trying to build a high traffic website and I'm trying to minimize the overhead as much as possible before starting to make any hardware scaling. Do you have any idea how can I "force" laravel 4 into lazy loading the classes, as in ... whenever they are requested by the code for the given request.
The way I see it now, when it parses the routes it includes all controllers, makes a reflection class of all of them to parse the methods so that it has them mapped in the request memory. IMO that's quite the overkill. A simple Hello World costs me 5Mb ram and 15ms page generation time. That is too much for me. It's like the most hyped framework at the moment and its hyped as lightweight but 5mb/15ms is not lightweight in any case :/
There is a great argument/explanation here: http://forums.laravel.io/viewtopic.php?id=8175
Laravel 4 is meant to use more framework agnostic packages than Laravel 3.
Laravel 3 is very lightweight, perhaps you could look into using v3 instead. It's still actively being used and supported throughout the community.
Related
This may silly question. But I am going to start new project. I am quite confused which framework is best out of Codegniter 3 and Laravel 5.
What is the main difference between them.
Thanks in Advance
Right now, I personally prefer Laravel since it supports PHP7 unlike CodeIgniter (I still haven't read if CodeIgniter 3 supports PHP7). And based on personal experience, Laravel (through Eloquent) has "beautifully-written-codes".
Here are some references for you to check out: (I made sure to post both sides to not be bias)
https://www.codeclouds.com/blog/laravel-vs-codeigniter-a-difficult-choice/
https://www.clickittech.com/developer/laravel-vs-codeigniter-which-one-is-the-best-to-use
http://www.codeigniterhands.com/codeigniter-or-laravel
http://laravel.io/forum/07-08-2014-laravel-vs-codeigniter-a-difficult-choice
https://therightsw.com/codeigniter-vs-laravel-vs-yii-vs-cakephp/ (with grades for usability)
Each framework have their own features and capabilities, used during the development of application. Laravel is one of the highly used, open-source modern web application framework that designs customized web applications quickly and easily.Laravel is used not only for big project but also best to use for small project.
Best framework in 2018
If you want a framework with exceptional performance, with nearly no configuration, not using cmd and not interested with large scale libraries and also your project is in small scale it's better to use codeIgniter.
CodeIgniter3 vs Laravel5
Both framework are good in there place.
Laravel made from multiple open source project which make laravel more efficient , reliable and secure.
Where, laravel used blade engine.
It used composer for package manager.
It provide unit testing.
It provide more security.
It provide beautiful redis queue front portal called laravel horizon.
Disadvantage : laravel used predis which is slower, because it is written in php.where phpredis is more faster, but laravel 5.* Don't support it.
I will recommend you to use Laravel beacuse of:
Built in authentication
Awesome migrations
Artisan commands to do anything in your project
Built in pagination (It's took long in Codeigniter)
Eloquent (Very easy way to interact with your database)
Relationships
Routes
Easy API building
Easy debugging
Huge number of packages and libraries etc.
This question already has answers here:
Differences and Similarities Between Lumen and Laravel
(8 answers)
Closed 6 years ago.
I'm going to make an API that will have many requests (around 5000 each minute minimum, but could possibly be a lot more). I'm wondering what framework is better for that: Laravel 5.2 or Lumen?
Lumen is a micro framework and especially made for API's but since Laravel 5.2 it's possible to change the middleware. So for my api I could only bind the middleware I need, so no authentication and so on.
That's a big difference with earlier versions of Laravel where the full framework was loaded. So is it since 5.2 still recommended to use Lumen or are the differences in performance very, very small?
There are some benchmarks out there for PHP frameworks. It's really hard to perform and read benchmarks in a good way, but they should still be able to hint about the difference between them. This seems like a good source: https://github.com/kenjis/php-framework-benchmark. That puts Lumen at 412.36 requests per second, and Laravel at 91.59 requests per second. If your API will have a lot of requests you should probably go with Lumen (or some even faster framework).
If you can you should also use PHP7 since the performance gains are huge compared to PHP5. You can decrease memory load an response times significantly, take a look at this benchmark for Symfony for example.
Disabling middleware for increasing performance is not a problem. There are different ways to register middleware in Laravel. Removing all middleware that comes by default in both the HTTP kernel and on routes is a small task. However there are a lot more to performance than the middleware. Laravel will bootstrap many components that you do not need, this is the reason why Lumen was created in the first place. I do not have a benchmark on how the middleware affects performance specifically, but I would assume it's not the main performance degrader.
The performance with Lumen will be way faster. Unless you are required to do some really complex operations that only Laravel / Laravel packages will handle, then just go with Lumen.
Also, if you're not going to make use of many features of Lumen or Laravel to a particular endpoint that's going to receive a lot of requests, just point that route to another PHP file in Nginx as there's no point in loading all of Laravel or Lumen's components if there is no need.
Good luck!
Having a Java background, one point I have missed during many years is that PHP recreates everything at every request.
So using the Symfony framework, we recreate every components of this - yet great - framework. Every service, all the router, are built and rebuilt.
We can cache data in $_SESSION, but we save 50 times data if we have 50 users. I thought I could use static or $_SERVER, but it doesn't work the Java way.
The PHP way is to use Memcached and there are plenty of exemples caching the doctrine requests, but I haven't seen any of them caching the Router or the Services. Do you know exemples, or is it just a bad idea ?
That's one of the characteristics of PHP, nothing lives once the request is finished.
There're a couple of projects where they wrap the bootstrapping process of symfony so it's only run once. Here's the project: php-pm and an article describing it's usage
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
we have an old large application that was not built on any framework. However now we want to transfer it to a php framework. Its a new area for us so we are not sure what it takes to transfer the older application to a framework like Zend?
You have three options:
Rewrite the application from scratch using the framework.
As another poster suggested, gradually start introducing ZF components into your application, the DB and View layers in particular would be good candidates. MVC would likely be the trickiest bit if your old app is large.
Create your new ZF application, add a 'legacy' module to it and put all of your old application code into this module. Route all requests to this module and get it to setup and load up whichever part of your old application needs to serve the request. You then gradually start adding ZF modules to replace parts of your old application (adjusting your routes accordingly), until eventually there's nothing left in 'legacy' and you can remove it.
Exactly which of these is the best option for you depends completely on your application. In my experience, option 1 will take the least dev time, option 2 the most and option 3 somewhere in the middle. With options 2 and 3 you have a transitional period where you're gradually introducing the new stuff, whereas with option 1, one day you just migrate all the data across and flick the switch.
The 'use at will' architecture of ZF is what makes option 2 possible, with other PHP frameworks you probably only have options 1 and 3.
Good luck!
Go sit and write it from scratch using framework. That's all.
Totally dependent on the makeup of the old framework.
Try to find components in Zend/CodeIgniter/CakePHP that closest resemble the functionality of the components in the old framework, then choose that library.
As far as I know, Zend Framework has an advantage as it can be used as a library.
You may work iteratively, adding for instance only the Zend_Db layer, then progressively adding other layers (Auth, MVC, etc.).
The point is to be able to test and validate simple functionnalities, rather then change all at once, and fight numerous bugs.