Laravel 5.1 with LTS is released • Hacker News Board

Re: Laravel 5.1 with LTS is released

#51

Post by lawry » Tue, Jun 09, 2015, 10:12 PM UTC

Killswitch wrote: post #41

bovermyer wrote: post #38

Earlier quoted context omitted.

An idempotent provisioner would be a better option. Ansible is my favorite.

I've tried Ansible and Puppet, but I just never could get used to them or like them. I like the shell provisioner because I know EXACTLY what it's doing. I can provision a server myself, I have the knowledge and understanding to. I can type up the commands in a bash script to provision it faster than I could learn exactly what Ansible or Puppet or Chef are doing when I tell it to install Nginx.

I get completely where you are coming from, the reason that I eventually got the hang of Ansible is because if you do it right (I mean using ansible's modules over scripts/commands) it adds the ability to rerun your ansible playbooks (think of them like those bash scripts) multiple times on the same cluster/node/server without worrying something will change because you run them more than once. Also bash on it's own has no templating feature, or easy way to check if something has already happend. And after a while the whole systems starts making sense.

I can only imagine your current bash-scripts are awesome and do tons of stuff for you, but I'd really like to suggest you give ansible another go, and ignore the different files for roles/vars/tasks in the beginning, just dump everything into one playbook, like your bash scripts do currently.

Re: Laravel 5.1 with LTS is released

#52

Post by lawry » Tue, Jun 09, 2015, 10:24 PM UTC

thethimble wrote: post #47

sirstompsalot wrote: post #34

Earlier quoted context omitted.

Great response, and you make a great point - focus on coding speed is a great reason to choose Laravel. It's also hugely popular and now with it's LTS, it's going to be around for a while. For me personally, I was a ZF 1.x guy; when I started a new project I chose Laravel, and it was a dream - crazy zippy (compared to ZF). But as I started to do more with it, I started to need to reduce my feature set, implement perf…

We're doing 2k req/s with Laravel for one of our API services. In order to maintain ~150ms of latency, this takes us ~14 c3.2xlarge boxes in a load balanced environment. We've done a lot of tuning to squeeze this much out of the boxes (nginx + php fpm) but ultimately I feel pretty let down by laravel/php. ~150 req/s per c3.2xlarge box is very disappointing. I'm hoping to migrate off and go with something like Scala+P…

I'm really glad to see I'm not the only one that feels the performance drop is painful, nowadays the only thing I do backend are API's, thus a lot of the features (like blade) are superfluous to me. I hope Lumen will kind of fix this, and be the perfect go-to framework for API's done in PHP.

Having said that, looking at the future it would make a lot more sense to switch to a different language altogether, it's a same my current employer only wants to run php backend (because it's 1 command to install, I know bad reason, but they don't want to support other languages). Why exactly are you looking at Scala or Go? I kind of get Scala (but I'd personally rather opt for Clojure), but why Go? Purely because it's much more performant than php? Doesn't this has to do with the lacking of such a full-featured framework like laravel?

Re: Laravel 5.1 with LTS is released

#53

Post by exclusiv » Wed, Jun 10, 2015, 8:07 AM UTC

thethimble wrote: post #47

sirstompsalot wrote: post #34

Earlier quoted context omitted.

Great response, and you make a great point - focus on coding speed is a great reason to choose Laravel. It's also hugely popular and now with it's LTS, it's going to be around for a while. For me personally, I was a ZF 1.x guy; when I started a new project I chose Laravel, and it was a dream - crazy zippy (compared to ZF). But as I started to do more with it, I started to need to reduce my feature set, implement perf…

We're doing 2k req/s with Laravel for one of our API services. In order to maintain ~150ms of latency, this takes us ~14 c3.2xlarge boxes in a load balanced environment. We've done a lot of tuning to squeeze this much out of the boxes (nginx + php fpm) but ultimately I feel pretty let down by laravel/php. ~150 req/s per c3.2xlarge box is very disappointing. I'm hoping to migrate off and go with something like Scala+P…

Have you tried HHVM?

Re: Laravel 5.1 with LTS is released

#54

Post by no1youknowz » Wed, Jun 10, 2015, 3:08 PM UTC

thethimble wrote: post #47

sirstompsalot wrote: post #34

Earlier quoted context omitted.

Great response, and you make a great point - focus on coding speed is a great reason to choose Laravel. It's also hugely popular and now with it's LTS, it's going to be around for a while. For me personally, I was a ZF 1.x guy; when I started a new project I chose Laravel, and it was a dream - crazy zippy (compared to ZF). But as I started to do more with it, I started to need to reduce my feature set, implement perf…

We're doing 2k req/s with Laravel for one of our API services. In order to maintain ~150ms of latency, this takes us ~14 c3.2xlarge boxes in a load balanced environment. We've done a lot of tuning to squeeze this much out of the boxes (nginx + php fpm) but ultimately I feel pretty let down by laravel/php. ~150 req/s per c3.2xlarge box is very disappointing. I'm hoping to migrate off and go with something like Scala+P…

Don't walk, RUN if you can to HHVM. Like you, I was running on amazon. Sure PHP runs at scale but then you have to load-balance. But come on, we had 20 servers at a cost of ~$6k a month. Thats just for the front-end also.

In August, I switched to HHVM and I was able to shrink down to a single server. Now I'm running 3 for things like redundancy. My bill? Around $1500 a month, big difference. No wonder Etsy, Wikipedia, Baidu and others have switched over.

Not only this, but 3.8 is coming with increased performance over 7. Not only RPS but also latency as well. I run an ad server and the latency DROP was huge compared to PHP.

Oh and for the backend application. Moving to HHVM it definitely feels much snappier than PHP. In some cases, you can see the difference. I don't regret moving to HHVM. Very very doubtful I'd move back to PHP 7.

My only 2 complaints are that Postgres and zeroMQ drivers are 3rd party extensions. There is talk of Postgres coming in house. I just wish more people could petition for ZeroMQ to be included.

If you do go to HHVM. Maybe it may be worth moving from Laravel to Slim (3)? You may get a boost due to the lower framework size? I know I did when going from Codeigniter to Slim 2.

Re: Laravel 5.1 with LTS is released

#55

Post by thethimble » Wed, Jun 10, 2015, 4:51 PM UTC

no1youknowz wrote: post #54

thethimble wrote: post #47

Earlier quoted context omitted.

We're doing 2k req/s with Laravel for one of our API services. In order to maintain ~150ms of latency, this takes us ~14 c3.2xlarge boxes in a load balanced environment. We've done a lot of tuning to squeeze this much out of the boxes (nginx + php fpm) but ultimately I feel pretty let down by laravel/php. ~150 req/s per c3.2xlarge box is very disappointing. I'm hoping to migrate off and go with something like Scala+P…

Don't walk, RUN if you can to HHVM. Like you, I was running on amazon. Sure PHP runs at scale but then you have to load-balance. But come on, we had 20 servers at a cost of ~$6k a month. Thats just for the front-end also. In August, I switched to HHVM and I was able to shrink down to a single server. Now I'm running 3 for things like redundancy. My bill? Around $1500 a month, big difference. No wonder Etsy, Wikipedia…

We ran some experiments with HHVM last year. Unfortunately, some random library that has a random dependency was failing on HHVM. The surface area for this type of incompatibility is a bit too much for me to bear.

PHP once had its place to make .html files dynamic. Unfortunately, the ease of making this happen accidentally turned PHP into what it is today. Beyond this, there isn't much merit to the language, the frameworks, or the ecosystem at all.

We're certainly running. But rather than stopping at HHVM, we're dropping PHP altogether.

Re: Laravel 5.1 with LTS is released

#56

Post by no1youknowz » Wed, Jun 10, 2015, 5:11 PM UTC

thethimble wrote: post #55

no1youknowz wrote: post #54

Earlier quoted context omitted.

Don't walk, RUN if you can to HHVM. Like you, I was running on amazon. Sure PHP runs at scale but then you have to load-balance. But come on, we had 20 servers at a cost of ~$6k a month. Thats just for the front-end also. In August, I switched to HHVM and I was able to shrink down to a single server. Now I'm running 3 for things like redundancy. My bill? Around $1500 a month, big difference. No wonder Etsy, Wikipedia…

We ran some experiments with HHVM last year. Unfortunately, some random library that has a random dependency was failing on HHVM. The surface area for this type of incompatibility is a bit too much for me to bear. PHP once had its place to make .html files dynamic. Unfortunately, the ease of making this happen accidentally turned PHP into what it is today. Beyond this, there isn't much merit to the language, the fram…

Have you looked at hhvm recently? A lot has changed since then and things have gotten better.

Although like you, I am eyeing golang as well. But not got any work scheduled until the latter part of this year.

Re: Laravel 5.1 with LTS is released

#57

Post by spronkey » Thu, Jun 11, 2015, 12:34 PM UTC

fideloper wrote: post #32

sirstompsalot wrote: post #21

Too bad it is still slow as a glacier.

This comment makes no sense. Well, it makes sense, but I don't believe it comes from someone who's really considered what they're saying. First, it's PHP. Same situation with Ruby and Python. All generally slow as a glacier (obvious exclusions being different implementations of said languages). Developers' focus on code speed is ridiculous (is that too strong a word?) due to relative inexpensiveness of "hardware" and…

For any nontrivial service that wants to build a large audience, something with the glacial performance of Laravel (and I use Laravel, so I'm not completely knocking it) has the downside that things you would normally do when much more mature crop up earlier. Like having to worry about horizontal scaling, or rewriting parts of your app in another language.

I'm not quite sure where L5's performance gets sunk so badly, but it really is a lot slower than earlier variants of the framework. About the only thing slower is Rails, really!

... and unlike Rails, Laravel hasn't had the stability and ecosystem to make those things really easy. Hopefully this LTS plan will change that a wee bit, but we'll see.