上线清单 —— 20 个 Laravel 应用性能优化项

让咱们开始吧！倘若你的 laravel 应用已经投入生产环境中。

从第一个用户，到第十，第一百，直到成千上万的用户！慢慢地，随着用户越多，你的网站会愈来愈慢

那咱们应该如何作？细节决定成败

通过一番搜索，我决定写下这20个使你网站提高速度的小提示

我将从基础开始，大部分都是能够瞬间完成的操做。而后，我将逐步提升难度。最后，就是更高级的内容了。若是你跟着个人步骤一步一步来，我相信你的网站会获得质的提高。

享受你的学习之旅！若是你有什么建议，能够在下方留言！我很高兴跟你们共同探讨。

基础的优化项

让咱们看看咱们可以在短短几秒钟内作些什么。

1. 路由缓存

每次服务器执行请求时，都会注册全部的路由，这会花费一些时间。可是，你能够选择缓存路由列表来跳过这个步骤。

缓存路由列表是很是简单的。你须要作的是在部署应用程序后，执行下面的这个命令：

php artisan route:cache
复制代码

可是，若是你添加或修改了任意一个路由信息，请不要忘记清除以前的缓存以及从新执行缓存命令。

php artisan route:clear

# 而后，再次执行
php artisan route:cache
复制代码

注意，这只对控制器类路由有效。

2. 缓存配置

就如路由同样，你一样能够在应用中缓存配置文件。

设想一下这种场景：每次你发送一个请求到 App 中，Laravel 都须要去加载不一样的配置文件，而且要去打开*.env* 文件读取其中的内容。这种方式性能低下，是不？

不过不用担忧，这里有个 Artisan 命令专治这个。

php artisan config:cache
复制代码

你在部署以后可使用它。和路由差很少，别忘了编辑东西的时候清理一下缓存。

php artisan config:clear

# 而后，再来一次...
php artisan config:cache
复制代码

3. 优化 Composer 自动加载

一般，Composer 生成自动加载文件很是快。可是，在生产环境中，若是设置了PSR-4 和 PSR-0 自动加载规则，这可能会变慢。

您能够经过将下面命令添加到部署脚原本优化自动加载器文件建立过程。

$  composer dump-autoload  -o
复制代码

不要忘记它。

4. 谣言：「不要大量使用 Blade 视图」

这个谣言我都听到头大了。

"千万不要大量使用 Blade 视图，由于它会使得应用性能下降！"

彻头彻尾的大谎话！认真脸！

铭记这个：Laravel 编译 Blade 视图。编译就是说，在流程结束时，你将拥有一个已编译的完整文件，而非使用多个文件。

因此，丝绝不须要担忧。

---

中级干货

5. 换个其余/更好的 Cache/Session 驱动

默认的，当你新建一个 Laravel 项目的时候Cache 和 Sessions 的驱动默认为 「文件」。在本地开发环境和小项目中它没啥问题，可是项目增加时事情就大条了。

因此，考虑下换个更好的驱动例如 Redis。 Laravel 有内置支持它的方式，而你要作的就是 安装 Predis。

更多细节在 这里和 此处。

6. 尽快升级 Laravel 版本

当新版本发布时，请记得尽快升级 Laravel。这不只关乎新功能：在可能的状况下，全部贡献者都花时间修复代码库周边的性能问题。

因此，要持续关注并保持代码更新。

7. 删除未使用的服务

这是不少人常常忘记的小技巧，要向本身提问：

"我须要它吗？*

咱们知道 Laravel 自带了不少服务，毕竟，这是一个全栈框架，每个服务都有其用武之地。

因此，请花一些时间检查 *config/app.php * 文件，看看你是否能找到一个你不须要的服务。若是一切正常，请尝试将其删除并测试您的应用程序。

它应该有所帮助（一点点）！

8. 使用预加载进行查询

若是你知道 Laravel 是什么，你可能也知道预加载是什么。 若是您信息不够及时，预加载是一种经过使用特定语法来减小发送到数据库的查询数量来提升 Eloquent 性能的方法。

此问题称为N + 1查询问题。 让咱们举个例子。 你有两个模型：Book 和 Author。 每本 book 都有它的 author。

$books  =  App\Book::all();

foreach  ($books  as  $book)  {
    echo  $book->author->name;
}
复制代码

想象一下，您的数据库中有1000本书。 如今，此代码将执行 ** 1001 ** 次查询以检索这1000本书的做者姓名。

1（查询以获取1000本书的数据）+ 1000（查询以获取每本书的做者数据）= 1001。

可是，若是你编写这样的代码

$books  =  App\Book::with('author')->get();

foreach  ($books  as  $book)  {
    echo  $book->author->name;
}
复制代码

更改基础查询以免此性能问题。 您将只执行两个查询而不是1001！ 这是巨大的性能提高。

9. 缓存查询结果

有时候， 缓存一个具体的查询结果多是一个好主意。

想象这样一个场景：你准备在你的应用主页上展现 “十大专辑” 排行榜。 这项工做是经过从数据库中执行查询完成的（查询可能涉及到artists表以及其余的一些表）。 你的主页访问量是 1000 次/小时 。

若是这个排行榜数据的查询次数是 1000次每小时，那么一天下来执行的查询次数就是24000次。 如今，让咱们假设这个排行榜是每小时更新一次 。那么，将每次的查询结果缓存一小时如何 ？

$value  =  Cache::remember('top_10_albums',  60,  function  ()  {
    return  Album::with('artist',  'producer')->getTopTen();
});
复制代码

这个缓存组件的 * remember* 方法在未找到缓存的状况下将会先从数据库中获取数据，并缓存60分钟。到期后，将会再次从数据库中获取最新的数据，更新缓存。

查询次数 从 24000 到 24 次/天 。

10. 为你的数据表创建索引

记住，必要的时候请为您的数据表创建索引。 这看起来像是个没什么卵用的提示，但实际上这颇有必要。 由于我见过很是多的应用，它们的数据表没有索引。

实现起来很简单，您能够建立一个新的数据库迁移并使用里面的方法来添加索引.

Schema::table('my_table_name',  function(Blueprint  $table){
    $table->index('field_to_be_indexed');
});
复制代码

固然，索引不是您喜欢在哪建就直接建立一个就是了。您必须研究您的业务、代码和查询，去分析哪里才是最须要索引的地方，而后再创建索引。

11. 中间件太多？

Laravel 会对你注册的中间件进行大量的（前/后）调用。因此，请你仔细检查它们，而且去掉那些你不须要的中间件。

一般中间件列表在 *Kernel.php *。

12. 是时候使用队列了！

有些时候，Laravel 比预期慢，这时你能够考虑异步执行任务。

最多见的状况就是发送一封欢迎邮件，让咱们一块儿看看任务流程。

1. 用户填写咱们的表单；
2. 将他/她的详细信息写入数据库；
3. 发送一封写有欢迎语和确认连接的邮件给他/她;
4. 并展现感谢页面；

不少时候，这些任务彻底是在控制器中而且按照顺序执行。

个人建议是学会如何使用事件和队列，能够将发送邮件任务交给专门的流程，以至于改善用户使用体验。

---

高级干货

13. 使用 Pusher 改进异步队列

上面我写了一些跟队列有关的内容。有时，你也可使用队列来改善面向用户的任务。

想象一下，你正在建立一个繁重的（在计算方面）进程，而且但愿给用户显示这个任务的进度条。你能够轻松地使用队列的异步任务并集成 Pusher 来向前端发送消息以达到目的，即便这个任务没有完成。

另外一个常用的示例是向用户发送消息不须要刷新页面。

考虑一下吧！

14. 使用 Logs / Debugbars / Laravel Telescope 测量调试工具

在提高本身方面，有一句我本身很是喜欢的引用。是从个人 CEO （感谢 Massimo ！）引用 Peter Drucker 的话那听来的。

若是你没法衡量它，你就没法改进它。

这个概念很是适合 Web 应用程序的上下文。要想改善 Web 应用的请求管理时间，须要测量不少东西。幸运地，咱们有许多很是优秀的工具来完成这件事。

• 慢日志： MYSQL ， MariaDB 和其余数据库能够启用慢日志来追踪那些语句花了大量的时间。你可使用这些数据来断定是否必须更改或优化特定的代码（或查询）；

• Debugbar ： Laravel Debugbar 是一个很棒的扩展包。在不少应用程序方面，你可使用它来收集数据。好比查询，视图，时间等等；

• Laravel Telescope ： 另外一个很是酷的工具是 Laravel Telescope ，对 Laravel 应用，有“优雅的调试助手”的美称。若是你感兴趣， 我已经在这里写了一篇关于它的文章 ；

15. 更新你的PHP版本

虽然这看起来很简单，可是若是你的项目够大的话，这执行起来会很麻烦，因此我以为把这条加入高级技巧里面。

若是你的 PHP 版本在7.0如下，更新你的 PHP 和 laravel 版本。

16. 在服务器上使用 Lumen

若是你的应用程序数据量增加很大，你能够考虑为你的系统作服务拆分了。不过，这并无一个明确的方法指南来引导你完成它：拆分标准的高与低取决于来自应用程序的领域到拆分全部必需的内容所需的工做中的许多因素。

可是，一旦你拆分红功，你的项目将得到新生。

若是你对这个主题感兴趣的话，能够从  medium.com/@munza/larg… 开始。

17. 为静态资源提供 CDN 服务

我很是确定你有不少前端的资源，好比 CSS 文件和 JS 脚本。

你能够经过多种方式来减小发送给用户的数据量：

• 压缩静态资源;
• 捆绑静态资源（将多个 CSS 文件或者 JS 脚本合并为一个，以减小请求次数）;
• 开启 gzip 压缩;

然而，若是你遇到大量的流量，则你能够将你的静态资源托管到专用的 CDN 服务器上，好比：

• Akamai（阿卡迈）;
• Max CDN;
• Cloudflare;
• 亚马逊 AWS 服务 (S3 + CloudFront);

译者注：国内可使用又拍云和七牛云

18. 使用高级测量工具

安装 Laravel Debugbar 或 Telescope 将是一个良好的开端，但对于更重大的项目，这还不够。

你须要选择更高级的工具，以下：

• New Relic;
• AppOptics;
• Datadog;
• Sentry;

以上列表的应用程序不作一样的事情：他们被设计用于不一样目的。花些时间去学习他们以理解他们如何提供帮助。

19. 垂直扩展

你已经对代码的细枝末节都进行了完全优化，可是你的应用体量在不断增加。早晚你都要进行垂直扩展。

有个简单的说法就是：更多的 RAM，更多的空间，更多的带宽就，以及更多的 CPU

注意这个只是对许多没有足够时间来安排重构/优化的初创公司的一般作法。法子是不错，因此你能够认为这是能让你喘口气的临时解决方案。

20. 水平扩展

水平扩展是另外一种扩展的方式，它不一样于传统的垂直扩展，主要有两点：

• 取代在现有配置上增长硬件资源的方式，你可能将会添加更多的功能模块来处理日益增长的流量。 在垂直扩展的环境中，你只须要增长服务器配置就行，可是水平扩展应用就意味着你的应用将会部署运行在不一样的机器上，有多是在一个负载均衡机器或者其余服务以后。这就意味着须要更多的设置和配置；此时事情就没那么简单了；
• 并不是全部的应用均可以在短期内扩展完毕，有时候你须要重构隔离一些代码；有时候你须要把应用拆分为不一样规模的小型服务。

水平扩展会有有不少事情要作，可是一旦你能对应用进行水平扩展时，好处也是超乎想象的。

结论

今天有足够的内容了！我经过合并个人我的经验和之前作过的一些研究建立了在这个列表。

若是你愿意，请尽管提出一些新东西，我很乐意相应更新一下此文章。

转自 https://learnku.com/laravel/t/24559