Is Laravel really so slow?

Question

I just started using Laravel. I haven’t written anything yet, but it takes almost a second for my pages to load!

This is a little shocking to me when my borderless and NodeJS apps take ~ 2 ms. What does laravel do? Is this not normal behavior? Do I need some fine tuning?

Answer 1

Laravel is actually not so slow. 500-1000ms is absurd; I got it up to 20 ms in debug mode.

The problem was in the Vagrant / VirtualBox + public folders. I did not know that they suffered such a blow to productivity. I think because Laravel has so many dependencies (uploads ~ 280 files), and each of these files reads slowly, it adds up very quickly.

Krives pointed me in the right direction, this blog post describes a new feature in Vagrant 1.5 that allows you to sync files in a virtual machine, rather than using a shared folder.

Windows does not have its own rsync client, so you have to use cygwin . Install it and be sure to check Net / rsync. Add C:\cygwin64\bin to your paths. [Or you can install it on Win10 / Bash]

Wagrant introduces a new feature . I use Puphet, so my Vagrantfile looks a little funny. I had to configure it like this:

  data['vm']['synced_folder'].each do |i, folder| if folder['source'] != '' && folder['target'] != '' && folder['id'] != '' config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{folder['id']}", type: "rsync", rsync__auto: "true", rsync__exclude: ".hg/" end end 

Once you're all set up, try vagrant up . If everything goes well, your machine should boot and copy all the files. You will need to run vagrant rsync-auto in the terminal to keep the files up to date. You will pay a little latent, but for the 30x page speed it’s worth it!

---

If you use PhpStorm, the automatic download function works even better than rsync. PhpStorm creates a lot of temporary files that can disable file viewers, but if you allow it to upload files yourself, this will work well.

---

Another option is to use lsyncd . I was very successful using this on the Ubuntu host -> FreeBSD guest. I have not tried this on a Windows host yet.

Answer 2

To help you with your problem, I found this blog post that talks about how to optimize laravel production. Most of what you need to do to quickly make your application will now be in the hands of how efficient your code is, your network capacity, CDN, caching, database.

Now I will talk about the problem:

Laravel slow out of the box. There are ways to optimize it. You also have the opportunity to use caching in your code, improving your server machine, yadda yadda yadda. But in the end, Laravel is still slow.

Laravel uses many symfony libraries, and, as you can see in techempower benchmarks , symfony is very low (the latter, to say the least). You can even find a laravel benchmark to be almost down.

In the background, a lot of startup occurs, which may not even load. So technically, since laravel is easy to use, it helps you quickly build applications, and also slows down work.

But I'm not saying that Laravel is bad, it's great , great for many things. But if you expect a big surge in traffic, you will need much more equipment to process requests. It will cost you a lot more. But if you are dirty rich, then you can achieve anything with Laravel .: D

The usual compromise:

  Easy = Slow, Hard = Fast 

I would have thought that C or Java has a complex learning curve and tight maintainability, but it occupies a very high place in web infrastructures.

Although it is not too connected. I'm just trying to prove easy = slow point:

Ruby has a very good reputation in maintainability and simplicity to learn it, but it is also considered the slowest among python and php, as shown here .

Answer 3

I found that the greatest speed increase with Laravel 4 you can achieve is choosing the right session drivers;

 Sessions "driver" file; Requests per second: 188.07 [#/sec] (mean) Time per request: 26.586 [ms] (mean) Time per request: 5.317 [ms] (mean, across all concurrent requests) Session "driver" database; Requests per second: 41.12 [#/sec] (mean) Time per request: 121.604 [ms] (mean) Time per request: 24.321 [ms] (mean, across all concurrent requests) 

Hope that helps

Answer 4

From my Hello World contest, which one is Laravel? I think you can guess. I used a docker container for the test and here are the results

Make http-response "Hello World":

• Golang with stdout log handler: 6000 rps
• SpringBoot with stdout log handler: 3600 rps
• Laravel 5 with protocol disabled: 230 rpm

Answer 5

Yes - Laravel is really very slow. For this, I created a POC application. Simple router with login form. I could only get 60 RPS with 10 parallel connections on a digital ocean server costing $ 20 (several GB RAM);

Setup:

 2gb RAM Php7.0 apache2.4 mysql 5.7 memcached server (for laravel session) 

I ran optimization, dump autoload linker, etc., and actually reduced RPS to 43 .

The problem is that the application responds in 200-400 ms. I checked the AB test from the local laravel machine was turned on (i.e. Not via web traffic); and I got only 112 RPS; with a response time of 200 ms with an average value of 300 ms.

Comparatively, I tested my PHP Native application to create several million requests per day on AWS t2.medium (x3, load balancing). When I AB'd 25 parallel connections from my local machine to this network, through ELB, I received approximately 1200 RPS. There is a huge difference on a machine with a load compared to the "login" page in laravel.

These are pages with sessions (elastic / memcached), real-time search queries (cached queries via memcached), assets extracted from CDN, etc. etc. etc.

What I can say, laravel sticks about 200-300ms load on things. This is great for PHP. Created views, after all, this type of delay is valid at boot time. However, for PHP views that use Ajax / JS to handle small updates, it starts to feel sluggish.

I can’t imagine how this system will look like using an application with several tenants, while 200 bots scan 100 pages each at the same time.

Laravel is great for simple applications. Lumen is tolerant if you do not need to do something that will require the meaninglessness of middleware (IE, not many applications for tenants and user domains, etc.);

However, I never wanted to start with something that can bind and cause a load of 300 ms for the message "hello world."

If you think, "Who cares?"

.. Write a predictive search that relies on quick queries to respond to auto-complete offers with hundreds of thousands of results. This lag of 200-300 m will lead you to madness.

Answer 6

I use Laravel quite a bit, and I just don’t believe the numbers that it tells me, because the end-to-end rendering measured by my browser shows LOWER the total time from the request to the readiness.

In addition, I get slightly higher numbers on my car at work, which makes the page noticeably faster than my car at home.

I don’t know how these numbers are calculated, but they are not confirmed by observation or browser tools like Firebug ...

Laravel is actually not so slow, especially when it is optimized. However, he is hungry in memory. Even a heavy CMS like Drupal, which is very slow, seems to have about 1/3 of the Laravel voice bone request memory.

Thus, in order to run Laravel in production, I would deploy servers with memory optimization to servers optimized for the CPU.

Answer 7

I know this is a little old question, but everything has changed. Laravel is not so slow. This, as already mentioned, synchronized folders are slow. However, on Windows 10, I was not able to use rsync . I tried both cygwin and minGW . rsync seems to be incompatible with git for windows ssh version.

Here's what worked for me: NFS .

Vagrant docs says:

NFS folders do not work on Windows hosts. Vagrant will ignore your request for synchronized NFS folders on Windows.

This is no longer the case. Currently we can use the vagrant-winnfsd plugin . It is really easy to install:

• Run vagrant plugin install vagrant-winnfsd
• Change your Vagrantfile : config.vm.synced_folder ".", "/vagrant", type: "nfs"
• Add to Vagrantfile : config.vm.network "private_network", type: "dhcp"

That is all I need for NFS to work. Laravel's response time decreased from 500 ms to 100 ms for me.

Answer 8

The following screenshot is an example without any implemented performance methods.

By default, the download speed of several models, http filters and containers.

Not much slower, you need to configure your Laravel correctly. Laravel has many optimization methods. Try some.

I used all the popular PHP frameworks for web application development, and my research shows that Laravel is the best framework for PHP in terms of

• Speed ​​/ Performance
• maintainability
• Developer Performance
• Convenience
• Localization
• Security
• Usability
• Scalability
• Testability
• deployment readiness

Answer 9

Laravel is slow because in most cases using PHP for web pages is slow.

With Laravel, the entire infrastructure is rebuilt with every call, so all pages point to index.php. Since the entire framework consists of PHP scripts, they must all go through the PHP interpreter - every time. The larger the frame, the longer it takes.

Compare this to the “server environment” (for example, tomcat), where the server runs the initialization code once, and in the end all the pages will be in their own code (after the JIT).

For example, when using the same hardware, OS, etc. The simple "hello world" using JSP on this equipment is 3000 r / s, the same hello world on laravel is 51 r / s.

The easiest way to test the framework overhead and the resulting maximum RPS per core is to use Apache AB and a concurrency value of 1 with a simple dynamic hello world (to avoid static page caching).