Laravel 真的这么慢吗？

Is Laravel really this slow?

提问by mpen

I just started using Laravel. I've barely written any code yet, but my pages are taking nearly a second to load!

我刚开始使用 Laravel。我还几乎没有写过任何代码，但我的页面需要将近一秒钟才能加载！

This is a bit shocking to me when my framework-less apps and NodeJS apps take ~2ms. What's Laravel doing? This isn't normal behaviour is it? Does it need some fine-tuning?

当我的无框架应用程序和 NodeJS 应用程序需要大约 2 毫秒时，这让我有点震惊。Laravel 在做什么？这不是正常行为吧？它需要一些微调吗？

回答by mpen

Laravel is notactually thatslow. 500-1000ms is absurd; I got it down to 20ms in debug mode.

Laravel实际上并没有那么慢。500-1000ms 是荒谬的；我在调试模式下将其缩短到 20 毫秒。

The problem was Vagrant/VirtualBox + shared folders. I didn't realize they incurred such a performance hit. I guess because Laravel has so many dependencies (loads ~280 files) and each of those file reads is slow, it adds up really quick.

问题是 Vagrant/VirtualBox + 共享文件夹。我没有意识到他们的表现受到了如此大的打击。我猜是因为 Laravel 有很多依赖项（加载约 280 个文件）并且每个文件读取都很慢，所以它加起来真的很快。

kreeves pointed me in the right direction, this blog postdescribes a new feature in Vagrant 1.5 that lets you rsync your files into the VM rather than using a shared folder.

kreeves 为我指明了正确的方向，这篇博文描述了 Vagrant 1.5 中的一项新功能，它允许您将文件 rsync 到 VM 中，而不是使用共享文件夹。

There's no native rsync client on Windows, so you'll have to use cygwin. Install it, and make sure to check off Net/rsync. Add C:\cygwin64\binto your paths. [Or you can install it on Win10/Bash]

Windows 上没有本机 rsync 客户端，因此您必须使用cygwin。安装它，并确保勾选 Net/rsync。添加C:\cygwin64\bin到您的路径。【或者你也可以安装在Win10/Bash上】

Vagrant introduces the new feature. I'm using Puphet, so my Vagrantfile looks a bit funny. I had to tweak it to look like this:

Vagrant 介绍了新功能。我正在使用 Puphet，所以我的 Vagrantfile 看起来有点滑稽。我不得不调整它看起来像这样：

  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 smoothly your machine should boot up and it should copy all the files over. You'll need to run vagrant rsync-autoin a terminal to keep the files up to date. You'll pay a little bit in latency, but for 30x faster page loads, it's worth it!

设置完成后，请尝试vagrant up。如果一切顺利，您的机器应该会启动并复制所有文件。您需要vagrant rsync-auto在终端中运行以使文件保持最新。您会在延迟上付出一点代价，但是对于 30 倍的页面加载速度来说，这是值得的！

---

---

If you're using PhpStorm, it's auto-upload feature works even better than rsync. PhpStorm creates a lot of temporary files which can trip up file watchers, but if you let it handle the uploads itself, it works nicely.

如果您使用 PhpStorm，它的自动上传功能比 rsync 效果更好。PhpStorm 创建了许多临时文件，这些文件可能会绊倒文件观察者，但是如果您让它自己处理上传，它会很好地工作。

---

---

One more option is to use lsyncd. I've had great success using this on Ubuntu host -> FreeBSD guest. I haven't tried it on a Windows host yet.

另一种选择是使用lsyncd。我在 Ubuntu 主机 -> FreeBSD 来宾上使用它取得了巨大的成功。我还没有在 Windows 主机上尝试过。

回答by majidarif

To help you with your problem I found this blogwhich talks about making laravel production optimized. Most of what you need to do to make your app fast would now be in the hands of how efficient your code is, your network capacity, CDN, caching, database.

为了帮助您解决问题，我找到了这个博客，其中讨论了如何优化 Laravel 生产。您需要做的大部分事情来使您的应用程序运行速度现在都掌握在您的代码效率、网络容量、CDN、缓存、数据库中。

Now I will talk about the issue:

现在我来谈谈这个问题：

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

Laravel 开箱即用很慢。有一些方法可以优化它。您还可以选择在代码中使用缓存，改进您的服务器机器，yadda yadda yadda。但最终 Laravel 仍然很慢。

Laravel uses a lot of symfony libraries and as you can see in techempower's benchmarks, symfony ranks very low (last to say the least). You can even find the laravel benchmarkto be almost at the bottom.

Laravel 使用了很多 symfony 库，正如您在techempower 的基准测试中看到的那样，symfony 排名非常低（至少最后一点）。你甚至可以发现 Laravel基准几乎在底部。

A lot of auto-loading is happening in the background, things you might not even need gets loaded. So technically because laravel is easy to use, it helps you build apps fast, it also makes it slow.

许多自动加载在后台发生，你甚至可能不需要的东西都被加载了。所以从技术上讲，因为 laravel 易于使用，它可以帮助您快速构建应用程序，也可以使其变慢。

But I am not saying Laravel is bad, it is great, great at a lot of things. But if you expect a high surge of traffic you will need a lot more hardware just to handle the requests. It would cost you a lot more. But if you are filthy rich then you can achieve anything with Laravel. :D

但我并不是说 Laravel 不好，它很棒，在很多方面都很棒。但是，如果您预计流量会激增，您将需要更多硬件来处理请求。这会让你付出更多的代价。但是如果你很有钱，那么你可以用 Laravel 实现任何目标。:D

The usual trade-off:

通常的权衡：

 Easy = Slow, Hard = Fast

I would consider C or Java to have a hard learning curve and a hard maintainability but it ranks very high in web frameworks.

我认为 C 或 Java 的学习曲线和可维护性都很难，但它在 Web 框架中的排名非常高。

Though not too related. I'm just trying to prove the point of easy = slow:

虽然关系不大。我只是想证明这一点easy = slow：

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

红宝石在可维护性和学习它的难易程度有很好的口碑，但它也被认为是Python和PHP中最低如图所示这里。

回答by Nick

Yes - Laravel IS really that slow. I built a POC app for this sake. Simple router, with a login form. I could only get 60 RPSwith 10 concurrent connections on a $20 digital ocean server (few GB ram);

是的 - Laravel 真的很慢。为此，我构建了一个 POC 应用程序。简单的路由器，带有登录表单。在 20 美元的数字海洋服务器（几 GB 内存）上，我只能获得60 RPS和 10 个并发连接；

Setup:

设置：

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

I ran optimizations, composer dump autoload etc, and it actually lowered the RPS to 43-ish.

我运行了优化、composer dump autoload 等，它实际上将 RPS 降低到 43-ish。

The problem is the app responds in 200-400ms. I ran AB test from the local machine laravel was on (ie, not through web traffic); and I got only 112 RPS; with 200ms faster response time with an average of 300ms.

问题是应用程序在 200-400 毫秒内响应。我在 laravel 所在的本地机器上运行了 AB 测试（即，不是通过网络流量）；而我只有 112 RPS；响应时间快 200 毫秒，平均为 300 毫秒。

Comparatively, I tested my production PHP Native app running a few million requests a day on a AWS t2.medium (x3, load balanced). When I AB'd 25 concurrent connections from my local machine to that over web, through ELB, I got roughly 1200 RPS. Huge difference on a machine with load vs a laravel "login" page.

相比之下，我测试了我的生产 PHP Native 应用程序，每天在 AWS t2.medium（x3，负载平衡）上运行几百万个请求。当我通过 ELB 从本地机器到 Web 的 AB 建立 25 个并发连接时，我获得了大约 1200 RPS。负载机器与 Laravel“登录”页面的巨大差异。

These are pages with Sessions (elasticache / memcached), Live DB lookups (cached queries via memcached), Assets pulled over CDNs, etc, etc, etc.

这些页面包含会话（elasticache / memcached）、实时数据库查找（通过 memcached 缓存查询）、通过 CDN 拉取的资产等，等等。

What I can tell, laravel sticks about 200-300ms load over things. Its fine for PHP Generated views, after all, that type of delay is tolerable on load. However, for PHP views that use Ajax/JS to handle small updates, it begins to feel sluggish.

我能说的是，laravel 对事物的负载大约为 200-300 毫秒。对于 PHP 生成的视图来说很好，毕竟这种类型的延迟在加载时是可以容忍的。但是，对于使用 Ajax/JS 处理小更新的 PHP 视图，它开始感到迟钝。

I cant imagine what this system would look like with a multi tenant app while 200 bots crawl 100 pages each all at the same time.

当 200 个机器人同时抓取 100 个页面时，我无法想象这个系统在一个多租户应用程序中会是什么样子。

Laravel is great for simple apps. Lumen is tolerable if you dont need to do anything fancy that would require middleware nonsense (IE, no multi tenant apps and custom domains, etc);

Laravel 非常适合简单的应用程序。如果您不需要做任何需要中间件废话的花哨的事情（IE，没有多租户应用程序和自定义域等），Lumen 是可以接受的；

However, I never like starting with something that can bind and cause 300ms load for a "hello world" post.

但是，我从不喜欢从可以绑定并导致“hello world”帖子加载 300 毫秒的内容开始。

If youre thinking "Who cares?"

如果你在想“谁在乎？”

.. Write a predictive search that relies on quick queries to respond to autocomplete suggestions across a few hundred thousand results. That 200-300ms lag will drive your users absolutely insane.

.. 编写一个预测搜索，该搜索依赖于快速查询来响应数十万个结果中的自动完成建议。200-300 毫秒的延迟会让您的用户绝对疯狂。

回答by Hydrino

I found that biggest speed gain with Laravel 4 you can achieve choosing right session drivers;

我发现 Laravel 4 的最大速度增益可以实现选择正确的会话驱动程序；

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

希望有帮助

回答by Aggarat .J

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

在我的 Hello World 比赛中，Laravel 是哪一个？我想你可以猜到。我使用 docker 容器进行测试，这是结果

To make http-response "Hello World":

制作 http 响应“Hello World”：

• Golang with log handler stdout : 6000 rps
• SpringBoot with Log Handler stdout: 3600 rps
• Laravel 5 with off log :230 rps

• 带有日志处理程序标准输出的 Golang：6000 rps
• 带有日志处理程序标准输出的 SpringBoot：3600 rps
• Laravel 5 关闭日志：230 rps

回答by AgmLauncher

I use Laravel quite a bit and I simply do not believe the numbers it tells me because end-to-end rendering as measured by my browser shows LOWER total time from request to ready.

我经常使用 Laravel，我只是不相信它告诉我的数字，因为我的浏览器测量的端到端渲染显示从请求到准备的总时间较短。

Further, I get slightly higher numbers on my machine at work, which does execute the page noticeably faster than my machine at home.

此外，我在工作时在我的机器上得到的数字略高，它执行页面的速度明显比我在家中的机器快。

I don't know how those numbers are getting calculated, but they are not corroborated by observation, or browser tools like Firebug...

我不知道这些数字是如何计算出来的，但它们并没有得到观察或 Firebug 等浏览器工具的证实......

Laravel is not actually all that slow, especially when optimized. It is memory-hungry however. Even a heavy CMS like Drupal which is very slow, appears to have about 1/3rd the memory footprint of a bare bones Laravel request.

Laravel 实际上并不是那么慢，尤其是在优化时。然而，它是内存饥渴的。即使是像 Drupal 这样非常慢的重型 CMS，它的内存占用似乎也只有 Laravel 裸机请求的大约 1/3。

Thus to run Laravel in production, I would deploy to memory-optimized servers before CPU-optimized servers.

因此，为了在生产环境中运行 Laravel，我会在 CPU 优化服务器之前部署到内存优化服务器。

回答by frutality

I know this is a little old question, but things changed. Laravel isn't that slow. It's, as mentioned, synced folders are slow. However, on Windows 10 I wasn't able to use rsync. I tried both cygwinand minGW. It seems like rsyncis incompatible with git for windows's version of ssh.

我知道这是一个有点老的问题，但事情发生了变化。Laravel 并没有那么慢。如前所述，同步文件夹很慢。但是，在 Windows 10 上我无法使用rsync. 我尝试了cygwin和minGW。似乎rsync与git for windows的版本不兼容ssh。

Here is what worked for me: NFS.

这对我有用：NFS。

Vagrant docssays:

流浪文档说：

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

NFS 文件夹在 Windows 主机上不起作用。Vagrant 将忽略您对 Windows 上 NFS 同步文件夹的请求。

This isn't true anymore. We can use vagrant-winnfsdpluginnowadays. It's really simple to install:

这已经不是真的了。我们现在可以使用vagrant-winnfsd插件。安装非常简单：

1. Execute vagrant plugin install vagrant-winnfsd
2. Change in your Vagrantfile: config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. Add to Vagrantfile: config.vm.network "private_network", type: "dhcp"

1. 执行 vagrant plugin install vagrant-winnfsd
2. 改变你的Vagrantfile：config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. 添加到Vagrantfile：config.vm.network "private_network", type: "dhcp"

That's all I needed to make NFSwork. Laravel response time decreased from 500ms to 100ms for me.

这就是我NFS工作所需的全部内容。对我来说，Laravel 响应时间从 500 毫秒减少到 100 毫秒。

回答by soheil yo

I faced 1.40swhile working with a pure laravel in development area!

我1.40s在开发区使用纯 Laravel 时遇到了问题！

the problem was using: php artisan serveto run the webserver

问题是使用：php artisan serve运行网络服务器

when I used apache webserver (or NGINX) instead for the same code I got it down to 153ms

当我使用 apache 网络服务器（或 NGINX）代替相同的代码时，我把它归结为 153ms

回答by turiyag

Since nobody else has mentioned it, I found that the xdebug debugger dramatically increased the time. I served a basic "Hello World, the time is 2020-01-01T01:01:01.010101" dynamic page and used this in my httpd.conf to time the request:

由于没有其他人提到它，我发现 xdebug 调试器大大增加了时间。我提供了一个基本的“Hello World，时间是 2020-01-01T01:01:01.010101”动态页面，并在我的 httpd.conf 中使用它来为请求计时：

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" **%T/%D**" combined

%T is the serve time in seconds, %D is the time in microseconds. With this in my php.ini:

%T 是以秒为单位的服务时间，%D 是以微秒为单位的时间。在我的 php.ini 中：

[XDebug]
xdebug.remote_autostart = 1
xdebug.remote_enable = 1

I was getting around 770ms response times, but with both of those set to 0 to disable them, it jumped to 160ms instantly. Running both of these brought it down to 120ms:

我得到了大约 770 毫秒的响应时间，但是当这两个都设置为 0 以禁用它们时，它立即跳到了 160 毫秒。运行这两个将其降低到 120 毫秒：

php artisan route:cache
php artisan config:cache

The downside being that if I made config or route changes, I would need to re-cache them, which is annoying.

缺点是如果我进行了配置或路由更改，我需要重新缓存它们，这很烦人。

As a sidenote, oddly, moving the site from my SSD to a spinning HDD provided no performance benefits, which is super odd to me, but I suppose it's maybe cached, I'm on Windows 10 with XAMPP.

作为旁注，奇怪的是，将站点从我的 SSD 移动到旋转 HDD 没有提供任何性能优势，这对我来说非常奇怪，但我想它可能被缓存了，我在 Windows 10 上使用 XAMPP。

回答by robert engels

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

Laravel 很慢，因为在大多数情况下，对网页使用 PHP 很慢。

With Laravel, the entire framework is rebuilt on every invocation - that is why all pages point to index.php. Since the entire framework is PHP scripts, they all need to go through the PHP interpreter - each time. The larger the framework, the longer this takes.

使用 Laravel，整个框架在每次调用时都会重新构建——这就是所有页面都指向 index.php 的原因。由于整个框架是 PHP 脚本，它们都需要通过 PHP 解释器——每次。框架越大，这需要的时间越长。

Contrast this with a "server environment" (e.g. tomcat) where the server runs the initialization code once, and eventually all pages will be in native code (after JIT).

将此与“服务器环境”（例如 tomcat）进行对比，其中服务器运行一次初始化代码，最终所有页面都将使用本机代码（在 JIT 之后）。

As a reference example, using the same hardware, OS, etc. a simple 'hello world' using JSP on this hardware is 3000 rps, the same hello world on laravel is 51 rps.

作为参考示例，使用相同的硬件、操作系统等。在此硬件上使用 JSP 的简单“hello world”为 3000 rps，laravel 上的相同 hello world 为 51 rps。

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

测试框架开销以及由此产生的每个内核最大 RPS 的最简单方法是使用 Apache AB 和并发值 1，以及一个简单的动态“hello world”（以避免静态页面缓存）。