Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

kobear's avatar

Adventures in increasing Laravel Performance

Hello all. I am a recent convert to the Laravel-way, and am so far incredibly impressed with it's overall awesomeness. I am building a niche social media platform that has the potential to be relatively popular, so while I am impressed with the ease of use of Laravel, I have been keeping a keen eye on the performance of my code as I go about the process of creating the full stack.

One of the great things about Laravel, IMHO, is the great community that surrounds it. With that in mind, I wanted to share my experiences with the community on my recent methods used to increase performance of my application.

First, the environment:

  • VMWare ESXi v5.1 host
  • CentOs 7 virtual machine
    • 2 x CPU cores (Intel Xeon 5150 @ 2.66Ghz)
    • 2 GB RAM
    • PHP 5.6.23
    • Apache 2.4.6
    • MySQL 5.6.31
    • Redis 3.2.1
    • Laravel 5.2

Initial performance was OK for a single user. I have a main activity page that loads as the home page, and using [debugbar] (https://github.com/barryvdh/laravel-debugbar) I could see that the total time for completion was on average 240ms. While I do not consider that stellar performance, it was ok for a single user. This page has lots of SQL queries, with only 6 items on the page having 38 SQL queries and 12 blade views to render.

What started me down the path of optimization was when I started using [Apache Benchmark] (https://httpd.apache.org/docs/2.4/programs/ab.html) to do some simple load tests on this page. A simple test running 10 seconds with 10 consecutive connections showed problems....

Requests per second: 14.84 [#/sec] (mean)

Uh oh.....

So, here is what I did.

1 - Increased CPU cores from 2 to 4, and memory from 2GB to 8GB

Simple enough. Really had no effect though.

Requests per second: 15.65 [#/sec] (mean)

meh

2 - Recompiled PHP to use opcache

Really don't understand why opcache wasn't installed to begin with, but it wasn't, so...

Requests per second: 25.65 [#/sec] (mean)

Ok, now we are seeing some results.

3 - Cached feed model records in Redis.

Using the Model::remember feature, cached results for 10 minutes.

Requests per second: 32.12 [#/sec] (mean)

4 - Modified Apache to use mpm-pre-fork module, increasing MaxClients and ServerLimit to 300

This is specific to my setup, since 300 is about right for 8GB of memory.

Requests per second: 65.01 [#/sec] (mean)

5 - Turned off debugging and lowered Laravel logging to "INFO"

Requests per second: 144.84 [#/sec] (mean)

Ok - that is MUCH better.

I will post more on this topic as time goes on. If anyone else has anything that they would like to add, please feel free to do so.

0 likes
17 replies
willvincent's avatar

Yeah php7 would make a huge difference too.. as would nginx vs apache

kobear's avatar

Agreed - my next steps are to switch to nginx, then PHP 7, then add varnish.

1 like
kobear's avatar

Any experience with HHVM and Laravel?

willvincent's avatar
Level 54

php7 is actually faster than HHVM in many cases. Especially php7 with opcode caching enabled.

Honestly I think once you get to the point of php7 with opcache, a good cache strategy for other content/variables/etc, nginx, maybe memcache, and varnish.. most anything else is usually diminished returns that aren't really worth the effort.

My personal website, even with the piggish overhead of Drupal, loads damn near instantly even when I'm authenticated and poking around the backend which cannot be cached by varnish. I am using APC for both opcode caching, and a key/value store cache backend, running nginx and have varnish in front of the whole stack. It is not yet running php7. But it's wicked fast.

3 likes
kobear's avatar

@willvincent Thanks for the info on PHP 7. I am spinning up a new dev server to install it on and see how that behaves. Thanks.

jlrdw's avatar

Remember @kobear speeds in development vs. Production is totally two different things.

2 likes
kobear's avatar

@jlrdw Yes, indeed. Just trying to measure orders of magnitude

willvincent's avatar

@kobear Redis is more robust, and has considerably more features. To be honest I don't have hands on experience with both, and only limited experience with memcache. I tried to use memcache for my cache backend on my personal site and found it considerably slower than using APC as my key/value store. Your mileage may vary of course.

Also, I think redis scales (horizontally) better than memcache, but I'm not certain on that.

This seems to be a pretty good comparison, ultimately making the case that redis is (almost always) a better choice: http://www.infoworld.com/article/3063161/application-development/why-redis-beats-memcached-for-caching.html

1 like
jimmck's avatar

@willvincent APC, Thank You! memcache is indeed slow. While it was fun writing things to keep track of whats inside the damm thing. Now to start reading.

1 like
bugsysha's avatar

For me PJAX brought lightning fast website sensation. So I would add that to the list.

willvincent's avatar

@ohffs I use nginx behind varnish. :)

It is also possible, albeit highly unorthodox, to have nginx talk directly to a cache backend, memcache for sure, others probably.

Here's a several years old article I read back when it came out about doing just that.. they tout a 53,900% improvement in speed.

kobear's avatar

@alenn Yes. That is with eager loading everything I can. It is an activity feed page, and uses polymorphic relations for statuses, posts, images, and such. So I expect there to be alot of queries on that page.

Please or to participate in this conversation.