2018 年 Laravel 和 Lumen 的运行效率对比

我正在重写我的项目 (Eyewitness.io)，为所有 Laravel 开发者创建一个免费版本（关于这方面的更多信息将在接下来的几周内公布）。

要处理来自数百个被监控的服务器的每分钟数千个连接，我目前使用 Lumen 来驱动 API ，同时使用 Laravel 为前端网站提供支持。

我之前写过关于可能将 Laravel 和 Lumen 合并成一个项目的文章(你可以在这里阅读)，但我不相信这是正确的答案。我还是发现自己要为 Lumen 做一些我想做的事情.

Jason McCreary (Laravel Shift创始人) 去年写了一篇文章 "Lumen is dead. Long Live Lumen"，我对他提到的一些观点产生共鸣。

注 --- 这并不是对 Lumen 的批判; 它是一个非常 优秀 的工具 并且有它的用武之地. 但是一旦你的 API 增长，我就发现我非常想用 Laravel 中的功能，但是在 Lumen 中并不能直接使用。

因此我就有一个想法; 在 现在 的2018年，Lumen 比 Laravel 到底快多少? 为什么说在2018年呢? 因为 Lumen 是早在2015年被推出的, 并且我现在我所能找到的大部分关于 Lumen 的基准测试都是在那个时间段的。

但是从2015年到2018年很多都已经发生变化; Redis 更快了。OPcache 现在是标配了。PHP7.2 相比于PHP5.6可以说是超级快了。并且 Laravel 的核心也更快了。

另一个问题就是我发现许多基准测试都是简单的“hello world”演示，并且没有做什么开箱即用的优化配置。 因此我想创建一个稍微 更真实的场景：

• Laravel 有config:cache和route:cache方法而Lumen没有，所以在测试中使用Redis是很重要的。
• Lumen 应该要有facades和eloquent的支持---因为我可以在我所有项目中使用它们去提升开发效率（我认为这适用于大多数人）。
• 实际上，大多数应用程序都涉及某种形式的数据库访问---所以我们需要在我们的测试中包括这些（facades和eloquent）
• Laravel现在拥有带有会话的web路由和无状态的api路由，所以当我们和Lumen比较的时候也需要在测试中包含这两个功能（即使是无状态的）。
• OPcache是现在的标准---所以让我们确保它是运行中的。
• 我发现大多数基准都是运行在本地的，我很想看看真正的网站在互联网上有什么样的表现。

*重要的一点：这个测试的目的只是为了确定 Lumen 相比 Laravel 有多快。 我对自己的实际数字不感兴趣---我只是想知道它们是如何相互关联的。

我创建了重复的 Laravel 和 Lumen 应用程序，每个都有三个路由；

• 没有数据库访问的 hello world 静态路由。
• 获取特定用户及其所有帖子的 show 路由（5条记录）。
• 一个 post/delete 路由，创建一个新的用户职位，然后删除它（以保持数据库大小在测试期间相同）。

我已经创建了一个要点，演示了在这里重新创建我的测试的确切步骤，以及GitHub回购
一: https://gist.github.com/laurencei/d46893f8...

我对 Laravel（web），Laravel（api）和 Lumen 的每条路线进行了Apache基准测试。 然后我重新进行了这些测试共5轮 （因为我发现测试结果每轮波动多达10％） 然后对结果进行平均。

下面是我在 DigitalOcean 2 GB 服务器上运行的内容（按照我的要求）：

所以毫无疑问，Lumen 肯定支持每秒更多的请求。

我也决定通过 Blackfire.io运行站点，然后看看运行的结果：

这意味着什么呢？ 根据 Blackfire.io显示的结果，对静态页面来讲，Lumen 比 Laravel（web）快290％。一旦启用 session ，Lumen（api） 只比 Laravel（api）快 75％ 了。

最令人感兴趣的是，当你将无状态的 Lumen 数据库访问与无状态的 Laravel 数据库访问进行比较时，Lumen（api）只比 Laravel（api）快大约25-30％。

换句话说---当你的应用程序开始使用数据库的时候，你就失去了 Lumen 提供的大部分 速度优势。

更进一步---如果你的应用程序有大型数据库和更复杂的SQL查询---那么性能上的差别可能会更小，因为与底层框架相比，数据库将成为瓶颈。 SQL查询耗时超过几毫秒将彻底消除 Lumen 提供的速度优势。

现在---有些人可能会读这个文章，说“哦买噶 ---速度提升30％，我选择 Lumen ” 。 但是我个人的看法是却相反的。 对于大多数项目来说，这是不足以成为一个差异证明 - 事实是，你将永远不会注意到这些差异，你的 API 用户也不会。 记住：Lumen 是无状态的，所以你通常只会使用它做API，而不是为用户显示一个网站。

我更喜欢拥有全套工具的 Laravel 和 其生态系统中的所有软件包所提供的开发速度。 即使节省了几个小时的开发时间，也能抵消一年额外的服务器成本。

从长远来看，着眼于编写优秀的可测试代码和寻找更好的优化（比如Vanish，数据库缓存，队列，Websockets等），可能会产生更好的结果。 在一个项目中使用我的API和网站将比单独开发它们节省相当多的开发时间。

但是，不是说每个人都要这样，并且每个项目或应用程序都会有不同的需求。 你需要自己权衡利弊，并进行特定于你的设置和场景的测试。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://medium.com/@laurencei/lumen-vs-l...

译文地址：https://learnku.com/laravel/t/7677/compa...