As someone who develops/maintains many high-IO requirement PHP microservices (as part of a service-oriented architecture, or, SOA), I'm torn on this one.
Laravel is one of my favorite frameworks, especially since 5.0 given its noble attempt to adhere to contract-first/interfaced development and many best practices that in some ways prevent the "worst" kinds of code from being written. It's not static typing, but it's a step in the right direction.
This seems like it's heavily optimized over the Laravel base, and if high speed and concurrency is important enough that you'd choose Lumen, then it seems like you'd still be stopping halfway in a bit of a "if you have a hammer everything seems like a nail" situation. Unless I'm missing something Lumen still requires resources to be bootstrapped on request, and ultimately that (in the context of a framework) will lead to memory leaks in a loosely-typed language; no way around that.
Also because disk writes will quickly become the bottleneck before your network capacity does, the two most relevant performance enhancements are to use a non-blocking event-loop (with expensive writes deferred to a tick cycle) and to completely avoid any unnecessary per-request bootstrapping--best done with raw PHP and ideally kept simple. This, combined with an optimized TCP configuration and split-per-process nginx LB at the head will give me r/s 10-50x the purported benchmarks. As much as 1000x when introducing intelligent edge-caching rules.
Is there a situation where this would be the right tool for the job/more ideal than the base framework but not worthy of a "roll-your-own" solution?
Either way +1 for Taylor Otwell as a developer and the general quality of his code/releases--Laravel is an ambitious project, and as a developer quite enjoyable to work with!
I guess if the micro service is using a bunch of shared code from a Laravel project (maybe just interfacing with the database) or if your team is large and already using Laravel, then the first step of optimizing a service into a 'micro service' is to use Lumen. Then step two (if Lumen isn't going fast enough) is to go raw PHP as you described.
But if your service is getting that popular, memory leaks are going to be a problem, maybe moving to HipHop (or whatever it's called now) or Node or something is a better idea.
I'm a php dev (amongst others) and I use it everyday at work but if I'm getting to the point where lumen or something like it is the bottleneck I'd just dump PHP altogether and go to a compiled language.
There is a niche I think for faster than laravel but not incredibly optimised, its another tool not the tool.
> Lumen still requires resources to be bootstrapped on request, and ultimately that (in the context of a framework) will lead to memory leaks in a loosely-typed language; no way around that.
Can you expand upon that or provide a link with more info? Why would it lead to memory leaks?
PHP frameworks have come a long way, and so has the language. The big thing that stands out, is that three of the best frameworks in the space (Laravel, Symfony and Slim) work together and feel a friendly/healthy sense of competition. They are reusing each others components and building a much more promising future for PHP.
Drupal 8 is based on Symfony -- things are really moving in the right direction.
Personally, I was a huge fan of Zend Framework + Doctrine, but these frameworks are all mature and great to use.... almost as good as Rails (lol, OK, OK, don't mention Ruby within earshot of PHP fans ;)
[edit] down voted for my opinion! Argh my tiny karma is depleted -- damn you ruby, damn you to hell!
Looks nice, I really like Slim Framework, this looks a lot like Slim from what I could tell. Gonna be interesting to see how (if at all) this will effect some performance focus from the Slim developers.
I've just created an issue [1] in our FrameworkBenchmarks project to solicit an implementation of our tests on Lumen. If anyone here is willing to contribute such an implementation, it would be greatly appreciated. The promise of performance caught my eye!
Looks really interesting. PHP may not be the "hip" language to use (although it's getting better), but it's so popular and accessible that disregarding it as a legitimate option for new projects is myopic.
I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language, so I'm not entirely convinced that PHP is really an excellent language (and runtime) that just happens to get a bad rap.
The drop in functionality right into the full framework is fantastic. Really like the ability to write API's with much less overhead, which was a factor that came into play for me recently. Nicely done Mr. Otwell.
The same holds true for Silex[1], the Symfony Components-based micro framework. Silex and Lumen look very similar (not only because Laraval/Lumen use Sf Components as well), not only because both use (just as Laravel) Sf Components. Slim 3 seems to move in the same direction of modern PHP frameworks, where you return a response from your controller, instead of setting up some global state (the main thing I don't like about Slim 1 & 2).
For now, Silex is still my favorite, as it has the temporary bonus of having more providers available to integrate 3rd party libraries. Sure, I can drop-in whatever library I like, but having someone do the setup (configuring Twig alone can be a burden if you want to get it right) just makes it easier for me ;)
This is definitely a very cool feature and makes this a very good candidate for MVP's or prototypes. I'm not a huge Laravel fan, but this feature alone might sway my decision.
This is a serious advantage to other frameworks if this principal holds true. I think anyone working in PHP has had their tails burnt a little too often with all the framework churn.
For a micro framework, highly recommend FatFreeFramework - You can see in the upcoming benchmarks how incredibly well it performs for a drop-in (non-compiled) framework...
http://www.techempower.com/benchmarks/previews/round10/#sect...
...Also I've found it much easier to learn and use than ones like laravel.
Also interested to see what projects use this as a core "micro framework" service or with an SOA architecture. Seems like good flexibility between framework power and lightweight.
I've just created a project with lumen to have a look at it and lumen and all its vendor packages (with --no-dev and without tests) contain 1522 files and 102449 lines of code – according to cloc.
Am I doing something wrong or why does it call itself a "micro-framework". A newly created Slim project contains 7417 lines of code.
How painless is deploying a Lumen/Laravel application? I used to use PHP back in 2006 and I remember deploying was as easy as pushing a .php file via FTP.
Has the experience remained the same? PHP was incredibly simple to deploy.
Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can.
However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:)
For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated.
Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to
1. Generate composer autoload cache files
2. Fetch, download and install any updated composer packages (i.e. third party libraries)
Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that.
How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines.
And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems.
Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)
If Lumen can use all Laravel its components, can't Laravel use Lumen its routing engine or whatever makes it that fast? What's the key difference that Lumen is considered "fast and micro" over a standard Laravel installation?
My understanding is that the majority of the advertised speed increase has to do with lazy initialization of the request/response stuff and the need to expressly ask for things like session support.
[+] [-] j42|11 years ago|reply
Laravel is one of my favorite frameworks, especially since 5.0 given its noble attempt to adhere to contract-first/interfaced development and many best practices that in some ways prevent the "worst" kinds of code from being written. It's not static typing, but it's a step in the right direction.
This seems like it's heavily optimized over the Laravel base, and if high speed and concurrency is important enough that you'd choose Lumen, then it seems like you'd still be stopping halfway in a bit of a "if you have a hammer everything seems like a nail" situation. Unless I'm missing something Lumen still requires resources to be bootstrapped on request, and ultimately that (in the context of a framework) will lead to memory leaks in a loosely-typed language; no way around that.
Also because disk writes will quickly become the bottleneck before your network capacity does, the two most relevant performance enhancements are to use a non-blocking event-loop (with expensive writes deferred to a tick cycle) and to completely avoid any unnecessary per-request bootstrapping--best done with raw PHP and ideally kept simple. This, combined with an optimized TCP configuration and split-per-process nginx LB at the head will give me r/s 10-50x the purported benchmarks. As much as 1000x when introducing intelligent edge-caching rules.
Is there a situation where this would be the right tool for the job/more ideal than the base framework but not worthy of a "roll-your-own" solution?
Either way +1 for Taylor Otwell as a developer and the general quality of his code/releases--Laravel is an ambitious project, and as a developer quite enjoyable to work with!
[+] [-] monk_e_boy|11 years ago|reply
But if your service is getting that popular, memory leaks are going to be a problem, maybe moving to HipHop (or whatever it's called now) or Node or something is a better idea.
Sounds like you're having fun!
[+] [-] noir_lord|11 years ago|reply
There is a niche I think for faster than laravel but not incredibly optimised, its another tool not the tool.
[+] [-] driverdan|11 years ago|reply
Can you expand upon that or provide a link with more info? Why would it lead to memory leaks?
[+] [-] dustinlakin|11 years ago|reply
[+] [-] monk_e_boy|11 years ago|reply
Personally, I was a huge fan of Zend Framework + Doctrine, but these frameworks are all mature and great to use.... almost as good as Rails (lol, OK, OK, don't mention Ruby within earshot of PHP fans ;)
[edit] down voted for my opinion! Argh my tiny karma is depleted -- damn you ruby, damn you to hell!
[+] [-] jcroll|11 years ago|reply
[+] [-] hising|11 years ago|reply
[+] [-] jonkiddy|11 years ago|reply
[+] [-] hising|11 years ago|reply
http://www.slimframework.com/2015/04/14/lumen.html
[+] [-] bhauer|11 years ago|reply
Incidentally, Round 10 is arriving soon.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/15...
[+] [-] imaginenore|11 years ago|reply
[+] [-] seandavidfisher|11 years ago|reply
[+] [-] pyre|11 years ago|reply
[+] [-] wesray|11 years ago|reply
[+] [-] xrstf|11 years ago|reply
For now, Silex is still my favorite, as it has the temporary bonus of having more providers available to integrate 3rd party libraries. Sure, I can drop-in whatever library I like, but having someone do the setup (configuring Twig alone can be a burden if you want to get it right) just makes it easier for me ;)
[1] http://silex.sensiolabs.org/
[+] [-] debaserab2|11 years ago|reply
[+] [-] cdnsteve|11 years ago|reply
[+] [-] quaffapint|11 years ago|reply
[+] [-] fideloper|11 years ago|reply
[+] [-] Beatus|11 years ago|reply
Am I doing something wrong or why does it call itself a "micro-framework". A newly created Slim project contains 7417 lines of code.
[+] [-] pan69|11 years ago|reply
[+] [-] debaserab2|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] sergiotapia|11 years ago|reply
Has the experience remained the same? PHP was incredibly simple to deploy.
[+] [-] alanstorm|11 years ago|reply
Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can.
However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:)
For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated.
Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to
1. Generate composer autoload cache files 2. Fetch, download and install any updated composer packages (i.e. third party libraries)
Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that.
How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines.
And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems.
Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)
[+] [-] mmmm|11 years ago|reply
[+] [-] cweagans|11 years ago|reply
[+] [-] ing33k|11 years ago|reply
[+] [-] JimmaDaRustla|11 years ago|reply
Slim 3 will also be PSR-7 compliant, I don't see anything about that anywhere in these Lumen docs.
[+] [-] giaour|11 years ago|reply
[+] [-] 0x0|11 years ago|reply
[+] [-] pearjuice|11 years ago|reply
[+] [-] McGlockenshire|11 years ago|reply
My understanding is that the majority of the advertised speed increase has to do with lazy initialization of the request/response stuff and the need to expressly ask for things like session support.
e: Here's an explanation from reddit, http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microf...
[+] [-] EGreg|11 years ago|reply
I think many frameworks allow you to include the "basic" subset of the framework, without running all the usual Inversion of Control bootstrapping.
[+] [-] evoratec|11 years ago|reply
[+] [-] ing33k|11 years ago|reply
[+] [-] jbrooksuk|11 years ago|reply
[+] [-] sneak|11 years ago|reply
[deleted]
[+] [-] ceejayoz|11 years ago|reply
[+] [-] adaml_623|11 years ago|reply
[+] [-] mildweed|11 years ago|reply