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?
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!
Drupal is becoming more and more insane with each release (especially 6 -> 7). The database structure is really getting out of hand. It's becoming harder and harder to deal with the performance issues.
Yeah... I don't know what to think about performance. We tend to be careful with page design and cache everything so once the cache is built the site flies.
But developing a drupal site is painful. Clearing the cache every few minutes takes forever.
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.
Have you ever tried Flight, http://flightphp.com? It has a smaller footprint than Slim but still has the ability to drop in PHP components. Disclaimer, I'm the author of Flight.
We (https://commando.io) use Flight for our API and love it. Super minimal, but provides all the functionality we require. The ability to map custom functions into the Flight namespace is great.
Curious, but why don't your docs request that the install be done with Composer? Manually downloading a tarball isn't the best solution for managing an application dependency.
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.
> I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language
What does it mean for a language to have memory leaks? Are you talking about a problem specific to the PHP runtime or common PHP idioms that lead to leaky code? A specific example would be helpful as I've never known PHP to be particularly vulnerable to memory-leak bugs (at least not any more than any of the other popular imperative scripting languages).
Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...."
Your comment seems to simply cast doubt without much substance.
PHP the runtime was built with a reload on every page load in mind, so a lot of cleaning up simply didn't need to happen. If it's in the runtime or how it's used doesn't matter.
It was a big deal when transitioning to the FPM runtime. That's why persistent PHP runtimes like FPM still have the option to completely reinitialize itself after a set number of pageviews. It's a bit like fixing leaks by rebooting, but it's fast enough not to be noticeable.
Admittedly, the "restart server process after N connections" method of dealing with memory leaks is not specific to just PHP.
It's also present in Apache, and thus mod_rails and mod_wsgi, by default[1], is an option in Gunicorn[2], and a gem is also available to provide the same in Unicorn.[3]
> What does it mean for a language to have memory leaks?
I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. Seeing as for a long time there was a single runtime paired with the language (I'm 99% sure that PHP4 didn't have alternate runtimes), I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things.
> Your comment seems to simply cast doubt without much substance.
And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks.
Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap?
> Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...."
Maybe I should have phrased that as "(e.g. memory leaks)" to show that memory leaks weren't the only complaint, but my memory fails me on what the other complaints were.
As far as I can tell, anecdotes, social proof, and familiarity play far more a role in the reputations of almost every language/tool than most engineers seem prepared to admit.
(But don't worry, dear reader -- you're probably the exception!)
PHP gets singled out for a bit of extra abuse (some perhaps justifiably, some not so much), but it's far from the only language whose popular conception is not so much based on thoughtful evaluation.
> I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced.
So are you talking about the default PHP 4 runtime or the default PHP 5.3 runtime or the default PHP 5.4 runtime etc? These versions are very different beasts, so levying a vague "memory leak" criticism at PHP without substantiating it via code or even a version makes the criticism pretty meaningless.
> I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things.
I asked for clarification because I was unsure what you were referring to. For example, about a month ago I was tasked with debugging a memory leak in a legacy Ruby application where I eventually discovered that the developer had used a proc in such a way that it prevented the GC from freeing variables that had been referenced in the closure. It was an issue somewhat similar to the examples described in this blog post:
I wouldn't attribute this memory leak to the Ruby langauge but more to a Ruby idiom that developers should take care to avoid. That's the type of clarification I'm looking for, but it appears that you don't really have anything to offer the discussion in this regard.
> And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks.
I have no emotions tied up in this discussion, I'm trying to make a point that your criticism is just anecdotal hearsay without any way for someone to verify if what you're saying is actually true. I didn't suggest that you ask your colleagues to file bug reports, I was simply pressing you for more details since your vague anecdote runs counter to my own experiences with PHP as I relate it to the rest of the imperative scripting landscape.
> Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap
Yes, that is pretty much the definition of "devoid of substance". "In the trenches" is a subjective description that doesn't mean anything. You presume they know what they're talking about, but maybe they actually don't, but we'll never know either way because all you've done is recount nebulous secondhand generalizations. You're not even asking me to take your word for it, you're asking me to take your word for their word. Can't you see why that's a little dubious?
I'm a PHP developer that works for a major media company. We do large scale deployments, and I'd like to say that PHP is a terrible language that gets a bad rap. It's getting better, and it's already 1000000x better than the PHP4 days, but it's still not a nice language. It's not a nice runtime. The only thing nice about it is that a zillion people and their dogs all know it and it's relatively easy to deploy.
In some ways they've introduced some powerful features bringing it on par with other languages, but the reality is that performance varies wildly in the real world because opcaches are finicky dependent on the data/request type/frequency and automated GC/circular-reference optimization is far from perfect.
Between HHVM (to effectively make memory growth linear vs logarithmic when approaching higher request concurrency) and sensible opcache tweaks you can make that runtime a bit less stochastic at scale, however if you don't know what you're doing PHP makes it so easy to go in the complete opposite direction without any indications you're running toward a cliff...
Are you suggesting that off-the-shelf frameworks/CMSes are somehow inferior to writing everything from scratch? That seems pretty myopic. We gain a lot from using Drupal.
We haven't been/won't be using it. Most of our traffic is anonymous, so we can optimize other parts of our stack. We'd rather not have to debug weird shit that comes up because of HHVM incompatibility.
I wouldn't be surprised if those memory leaks were due to an older version of PHP (GC was recently improved a lot to clean up circular references) or a poorly-written framework, which most of them are. Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory.
I've used PHP a few times in the past for some long-running, complex cron jobs, and I never had memory leaks. I've also never noticed it for short-running HTTP responses, and some of those have been really awful and messy because I'm more of a PHP doctor than someone who starts projects with it.
Anyway, everyone is going to benefit from HHVM. If Facebook uses it in production, you can be sure that it won't have any common memory leaks for long.
> Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory.
IIRC arrays are always passed by reference and only duplicated if you modify the data inside the called function (if not passed with '&' of course) ?
> Duplicating an array in memory every time it is passed to or from a function would be awful.
This might be because I originally learned PHP about 16 years ago, but I could swear this used to be the case. There's definitely a reason PHP has the reputation it has, although many of those glaring issues have since been fixed.
I started with PHP3 and also didn't know or care about that for a long time. Then Doctrine with its hydrators and PHP daemons became a thing in the workplace and all of sudden you have to be a bit more careful with data size and memory management.
Call-time pass-by-reference (passing with '&') has been either deprecated or removed. It has to be done in the function signature.
> only duplicated if you modify the data inside the called function
I did not know that. Because I've observed the duplication behavior, I assumed that it was never a reference. I guess that's a "feature" when you don't really have any fine-grained, explicit control over pointers or references.
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 ;)
I've done some projects with Silex and it's not bad but I've found myself losing quit a bit of time because you can never really use most components exactly like in the Symfony standard distribution but the docs mostly show you that way.
Also you have to be careful with dependencies version or you're quickly in Composer hell (because Symfony moves forward so fast).
Always wanted to compare it with Slim but didn't take the time.
I've used "Silex" and "Slim" in various small projects and API's. Then I found PhalconPHP.com I prefer using Micro+Volt now. New version 2.0 will be released on April 17th, 2015 So check it out, you may like "volt" template engine more :-)
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.
Lines of code is obliviously not a benchmark to rank a micro framework.
The term "mirco" refers to the amount of functionality the framework exposes. Often a micro framework is just a router decorated with some other useful stuff. Who cares about lines code, especially when you count "all" dependencies in vendor.
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 :)
> They really aren't similar at all. Forge manages sub-domains, Nginx, Cron jobs, SSL certificates, queue daemons, recipes, etc. Envoyer does none of those things. Envoyer is solely focused on deploying PHP applications to multiple servers with zero downtime.
Lumen uses the same request and response objects as Laravel, which extend Symfony's request and response objects, on which PSR-7 is based. If Lumen isn't PSR-7 compliant once that standard is finalized, it will be shortly.
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.
Laravel's strength is that it is batteries included but for some stuff this can be a weakness, API's where that 30-40ms load time matters for example.
I've spent a couple of years working with and on laravel projects and mostly I like it a great deal but it is a sledgehammer when sometimes you need a ballpein.
You've misunderstood. He only uses that (flat) array to populate the key-value array $c. His problem is that PHP oh-so-helpfully converts the string value to an int value. It's actually impossible to have string values as indices of an array when they are parsable as numbers in PHP. One of the many foibles that stem from conflating flat arrays and key-value maps. (For a real fun time, try reading the docs for array_merge.)
Anyway, it's not surprising. /r/PHP doesn't handle criticism well.
It is ok. That's how the language is designed so that arrays cover both hash-map use cases and traditional numerically indexed array use cases. The behavior is well documented and in this specific example, using a == instead of a === would cause the desired result. The poster of that comment should RTFM.
I am not sure I should go read the manual before setting a string key in an array to make sure that the specific string does not falls under some kind of special treatment. When normal people see that they can set string keys on something, they would assume that it work for all strings regardless of their content.
And regarding PHP manual, it does not even have fundamental stuff right. This comment is from an ex php core developer.
>using a == instead of a === would cause the desired result
Except using == will result in a hundred other weird behaviors that have caused numerous many bugs and security vulnerabilities, that every one uses === with out exception..
And you said anyone using PHP in 2015 is doing it wrong, which given that you don't know what "the job" someone might be using it for, seems to head over to the "hating on it" territory.
PHP in 2015 means great frameworks like Symfony/Laravel, high performance with HHVM (and soon PHP7), good package management with Composer, etc. It has made great strides.
It's playing catch-up, and it's severely hampered by its refusal to break backwards compatibility for anything. I did a PHP contract last year after not having done PHP in years. I had genuinely high hopes for it because of having seen sentiments like yours. And Symfony is a pretty okay framework (but not great), Composer is decent, and HHVM is a pretty fast VM. But the language itself has fundamentally not changed at all -- it's still flawed in deep ways, while the developers seem mainly preoccupied with adding as many features from Java as they can. In 2015, I see someone defending PHP and I think they simply don't know any other language.
Well, consider that Silex and Slim have been out for a while already and no, not really. I think it's about having options more than anything else at this point
This attitude, the illusion that RoR is year zero in software development is the #1 reason why Rails has become toxic for many companies.
Hordes of hipster RoR developers making the same mistakes all over again because they refuse to learn from mistakes already made by others. Turning project after project into an unmanageable mess with a marginal life expectancy because they believe their superior elegant language and one-size-fits-all opinionated framework means they don't have to think about architecture and design.
In all my years I've never seen a developer movement piss away its initial success so rapidly as the Rails community.
> What Rails is to Laravel, Sinatra is to lumen. Nothing more than another copycat idea from the ruby/rails world.
I must be misunderstanding your point, because the way I read what you wrote, you are insinuating that incorporating good ideas already implemented in a different incompatible technology stack is worthless.
E.g. making a good text editor for windows is worthless because vim/emacs exists, or making a python library for parsing HTML is worthless because there is already a perl one?
I worked at a company that did remote energy monitoring (circuit by circuit, minute by minute for thousands of monitors). We did all the math in PHP, preping, summarizing data and sending it down to web services. It wasn't fast, but it couldn't be considered slow by any stretch.
Plus php has a large library of components (Zend, symfony) and a package manager (composer) that make web development significantly easier.
Well, I'm sure there were a number of key factors involved.
I'm currently porting a rails app to Laravel and the speed boost has been pretty remarkable, not to mention not ever having to install gems whose only purpose is to reboot unicorn when the memory leaks hit a certain threshold.
I didn't choose Laravel because I like PHP (I don't), I chose it because of the need to balance ease of development with speed with having less skilled developers be able to maintain it with a modicum of safety. Not to mention how ridiculously easy it is to horizontally scale PHP.
I'd like PHP more if they dropped the f*cking $ sign though.
The dollar sign usually only bothers me after I've gone away and written a little Python. Actually, has anyone ever tried a 'CoffeeScript for PHP' that removed the dollar sign, replaced the `->` with dot syntax, and smoothed over the various other syntax features that people complain about? Not that I'd think there'd be much point really, apart from being a fun project.
My only hesitation with it has been that you need Node.js to compile it to regular PHP -- it offers no analogue to coffeescript's eval-in-browser mode for development.
And what would you propose using instead? Every language has its ups and downsides and the majority of problems (anecdotally anyways) come not from the language but the data store availability and ability to scale anyways.
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!