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.
Yes! Haha I realized that when I'm working double the hours without noticing, because the challenges are finally unique enough to be interesting :)
I think you hit the nail on the head again too, since frameworks as a philosophy don't intrinsically value shared-nothing (SN) principles which is the other 'dimension' to scalable concurrency--from a devops perspective, anyway.
And while there's never complete isolation, minimizing that interdependence makes your builds that much more environment-agnostic, and easy to provision dynamically.
Honestly what I'd love to see is a kernel-up PHP environment/container that doesn't focus on runtime in isolation, but the entire TCP stack from syscntl to the webserver (h2o?) and maybe even with some experimental support to extract frequent commands to compiled modules with C headers.
But by that point you'd probably just be using Go or Haskell because that's what compiled, statically-typed languages are for ;)
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?
Comments
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.
Sounds like you're having fun!
Yes! Haha I realized that when I'm working double the hours without noticing, because the challenges are finally unique enough to be interesting :)
I think you hit the nail on the head again too, since frameworks as a philosophy don't intrinsically value shared-nothing (SN) principles which is the other 'dimension' to scalable concurrency--from a devops perspective, anyway.
And while there's never complete isolation, minimizing that interdependence makes your builds that much more environment-agnostic, and easy to provision dynamically.
Honestly what I'd love to see is a kernel-up PHP environment/container that doesn't focus on runtime in isolation, but the entire TCP stack from syscntl to the webserver (h2o?) and maybe even with some experimental support to extract frequent commands to compiled modules with C headers.
But by that point you'd probably just be using Go or Haskell because that's what compiled, statically-typed languages are for ;)
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.
Bingo.
At that point you've hit on the essential purpose/elegance of static types and a compiler :)
Can you expand upon that or provide a link with more info? Why would it lead to memory leaks?