记一次 Laravel 应用性能调优经历
1009448750
6年前
<p>这是一份事后的总结。在经历了调优过程踩的很多坑之后，我们最终完善并实施了初步的性能测试方案，通过真实的测试数据归纳出了 Laravel 开发过程中的一些实践技巧。</p> <h2>0x00 源起</h2> <p>最近有同事反馈 Laravel 写的应用程序响应有点慢、20几个并发把 CPU 跑满... 为了解决慢的问题，甚至一部分接口用 nodejs 来写。</p> <p>而我的第一反应是一个流行的框架怎么可能会有这么不堪？一定是使用上哪里出现了问题。为了一探究竟，于是开启了这次 Laravel 应用性能调优之旅。</p> <h2>0x01 调优技巧</h2> <p>这次性能测试方案中用到的优化技巧主要基于 Laravel 框架本身及其提供的工具。</p> <ol> <li>关闭应用debug app.debug=false</li> <li>缓存配置信息 php artisan config:cache</li> <li>缓存路由信息 php artisan router:cache</li> <li>类映射加载优化 php artisan optimize</li> <li>自动加载优化 composer dumpautoload</li> <li>根据需要只加载必要的中间件</li> <li>使用即时编译器（JIT），如：HHVM、OPcache</li> <li>使用 PHP 7.x</li> </ol> <p>除了以上优化技巧之外，还有很多编码上的实践可以提升 Laravel 应用性能，在本文中暂时不会做说明。（也可以关注我的后续文章）</p> <h3>1. 关闭应用 debug</h3> <p>打开应用根目录下的 .env 文件，把 debug 设置为 false。</p> <pre> APP_DEBUG=false</pre> <h3>2. 缓存配置信息</h3> <pre> php artisan config:cache</pre> <p>运行以上命令可以把 config 文件夹里所有配置信息合并到一个 bootstrap/cache/config.php 文件中，减少运行时载入文件的数量。</p> <pre> php artisan config:clear</pre> <p>运行以上命令可以清除配置信息的缓存，也就是删除 bootstrap/cache/config.php 文件</p> <h3>3. 缓存路由信息</h3> <pre> php artisan route:cache</pre> <p>运行以上命令会生成文件 bootstrap/cache/routes.php 。路由缓存可以有效的提高路由器的注册效率，在大型应用程序中效果越加明显。</p> <pre> php artisan route:clear</pre> <p>运行以上命令会清除路由缓存，也就是删除 bootstrap/cache/routes.php 文件。</p> <h3>4. 类映射加载优化</h3> <pre> php artisan optimize --force</pre> <p>运行以上命令能够把常用加载的类合并到一个文件中，通过减少文件的加载来提高运行效率。这个命令会生成 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 两个文件。</p> <p>通过修改 config/compile.php 文件可以添加要合并的类。</p> <p>在生产环境中不需要指定 --force 参数文件也可以自动生成。</p> <pre> php artisan clear-compiled</pre> <p>运行以上命令会清除类映射加载优化，也就是删除 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 两个文件。</p> <h3>5. 自动加载优化</h3> <pre> composer dumpautoload -o</pre> <p>Laravel 应用程序是使用 composer 来构建的。这个命令会把 PSR-0 和 PSR-4 转换为一个类映射表来提高类的加载速度。</p> <p>注意： php artisan optimize --force 命令里已经做了这个操作。</p> <h3>6. 根据需要只加载必要的中间件</h3> <p>Laravel 应用程序内置了并开启了很多的中间件。每一个 Laravel 的请求都会加载相关的中间件、产生各种数据。在 app/Http/Kernel.php 中注释掉不需要的中间件（如 session 支持）可以极大的提升性能。</p> <h3>7. 使用即时编译器</h3> <p>HHVM 和 OPcache 都能轻轻松松的让你的应用程序在不用做任何修改的情况下，直接提高 50% 或者更高的性能。</p> <h3>8. 使用 PHP 7.x</h3> <p>只能说 PHP 7.x 比起之前的版本在性能上有了极大的提升。</p> <p>嗯，限于你的真实企业环境，这个也许很长时间内改变不了，算我没说。</p> <h2>0x02 测试方案</h2> <p>我们使用简单的 Apache ab 命令仅对应用入口文件进行测试，并记录和分析数据。</p> <ol> <li>仅对应用的入口文件 index.php 进行测试，访问 “/” 或者 “/index.php” 返回框架的欢迎页面。更全面的性能测试需要针对应用的更多接口进行测试。</li> <li>使用 Apache ab 命令。 ab -t 10 -c 10 {url} 。该命令表示对 url 同时发起 10 个请求，并持续 10 秒钟。命令中具体的参数设置需要根据要测试的服务器性能进行选择。</li> <li>为了避免机器波动导致的数据错误，每种测试条件会执行多次 ab 命令，并记录命令执行结果，重点关注每秒处理的请求数及请求响应时间，分析并剔除异常值。</li> <li>每次对测试条件进行了调整，需要在浏览器上对欢迎页进行访问，确保没有因为测试条件修改而访问出错。如果页面访问出错会导致测试结果错误。</li> </ol> <p>服务器环境说明</p> <p>所有脱离具体环境的测试数据都没有意义，并且只有在相近的条件下才可以进行比较。</p> <ol> <li>这套环境运行在 Mac 上，内存 8G，处理器 2.8GHz，SSD 硬盘。</li> <li>测试服务器是使用 Homestead 搭建的。虚拟机配置为单核 CPU、2G 内存。</li> <li>服务器 PHP 版本为 7.1，未特殊说明，则标识开启了 OPcache。</li> <li>测试的 Laravel 应用程序采用 5.2 版本编写。 app\Http\routes.php 中定义了 85 个路由。</li> <li>测试过程中除了虚拟机、终端及固定的浏览器窗口外，没有会影响机器的程序运行。</li> </ol> <p>以上的数据，大家在自己进行测试时可以参考。</p> <h2>0x03 测试过程及数据</h2> <h3>1. 未做任何优化</h3> <p>1.1 操作</p> <ul> <li>按照以下检查项执行相应的操作。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php</li> </ul> <p>基础检查项</p> <ul> <li>.env 文件中 APP_DEBUG=true</li> <li>不存在 bootstrap/cache/config.php</li> <li>不存在 bootstrap/cache/routes.php</li> <li>不存在 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json</li> <li>app/Http/Kernel.php 中开启了大部分的中间件</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问</li> </ul> <p>1.2 数据记录</p> <p><img src="https://simg.open-open.com/show/39e700b5d901cf142f7293abd911b6f0.jpg"></p> <h3>2. 关闭应用debug</h3> <p>2.1 操作</p> <ul> <li>在步骤 1 基础上修改 .env 文件中 APP_DEBUG=false 。</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php 。</li> </ul> <p>2.2 数据记录</p> <p><img src="https://simg.open-open.com/show/929934476310bd57162562287b1f313c.jpg"></p> <p>2.3 对比结果</p> <p>与步骤 1 结果比较发现：关闭应用 debug 之后，每秒处理请求数从 26-34 上升到 33-35，请求响应时间从 大部分 300ms 以上下降到 290ms 左右， <strong>效果不太明显，但确实有一定的提升。</strong></p> <p>注意：这部分与应用中的日志等使用情况有比较大的关联。</p> <h3>3. 开启缓存配置信息</h3> <p>3.1 操作</p> <ul> <li>在步骤 2 基础上，运行 php artisan config:cache ，确认生成 bootstrap/cache/config.php 。</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php 。</li> </ul> <p>3.2 数据记录</p> <p><img src="https://simg.open-open.com/show/b251e772af1782188da258f359831e9e.jpg"></p> <p>3.3 对比结果</p> <p>与步骤 2 结果比较发现：开启配置信息缓存之后，每秒处理请求数从 33-35 上升到 36-38，请求响应时间从 290ms 左右下降到 260ms 左右， <strong>效果不太明显，但确实有一定的提升。</strong></p> <h3>4. 开启缓存路由信息</h3> <p>4.1 操作</p> <ul> <li>在步骤 3 基础上，运行 php artisan route:cache ，确认生成 bootstrap/cache/routes.php 。</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php 。</li> </ul> <p>4.2 数据记录</p> <p><img src="https://simg.open-open.com/show/33694b1ceabecb3bbd054b3768681f61.jpg"></p> <p>4.3 对比结果</p> <p>与步骤 3 结果比较发现：开启路由信息缓存之后，每秒处理请求数从 36-38 上升到 60 左右，请求响应时间从 260ms 下降到 160ms 左右， <strong>效果显著，从 TPS 看，提升了 70%。</strong></p> <h3>5. 删除不必要的中间件</h3> <p>5.1 操作</p> <ul> <li>在步骤 4 基础上，注释掉不必要的中间件代码。</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php 。</li> </ul> <p><img src="https://simg.open-open.com/show/8a99f7b93dcb8b395687e78d8c7f2b6e.jpg"></p> <p>注意：这次测试中我注释掉了所有的中间件。实际情况中应该尽量只留下必要的中间件。</p> <p>5.2 数据记录</p> <p><img src="https://simg.open-open.com/show/4ab2ef32c5e11777c5746d4ac5be1d04.jpg"></p> <p>5.3 对比结果</p> <p>与步骤 4 结果比较发现：删除了不必要的中间件之后，每秒处理请求数从 60 左右上升到 90 左右，请求响应时间从 160ms 下降到 110ms 左右， <strong>效果非常明显，从 TPS 看，提升了 50%。</strong></p> <h3>6. 开启类映射加载优化</h3> <p>6.1 操作</p> <ul> <li>在步骤 5 基础上，运行 php artisan optimize --force ，确认生成 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 。</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php 。</li> </ul> <p>6.2 数据记录</p> <p><img src="https://simg.open-open.com/show/75a610a2225bfce677a2700deef9a2fb.jpg"></p> <p>6.3 对比结果</p> <p>与步骤 5 结果比较发现：做了类映射加载优化之后，每秒处理请求数从 90 上升到 110，请求响应时间从 110ms 下降到 100ms 以下， <strong>效果还是比较明显的。</strong></p> <h3>7. 关闭 OPcache</h3> <p>7.1 操作</p> <ul> <li>在步骤 6 基础上，关闭 PHP 的 OPcache，并重启服务器。通过 phpinfo() 的 Zend OPcache 确认 OPcache 已经关闭。</li> <li>浏览器访问 Laravel 应用程序欢迎页确保正常访问。</li> <li>运行 ab -t 10 -c 10 http://myurl.com/index.php 。</li> </ul> <p>7.2 数据记录</p> <p><img src="https://simg.open-open.com/show/5fabf84df55efef98e7faf507844abf5.jpg"></p> <p>7.3 对比结果</p> <p>与步骤 6 结果比较发现：关闭 OPcache 之后，每秒处理请求数从 110 下降到 15，请求响应时间从 100ms 以下上升到 650ms 以上。 <strong>开启与关闭 OPcache，数据上竟有几倍的差别。</strong></p> <p>此后，我重新开启了 PHP 的 OPcache，数据恢复到步骤 6 水平。</p> <h2>0x04 踩过的坑</h2> <h3>1. [LogicException] Unable to prepare route [/] for serialization. Uses Closure.</h3> <p>在运行 php artisan route:cache 命令时报这个错误。</p> <p>原因：路由文件中处理“/”时使用了闭包的方式。要运行该命令，路由的具体实现不能使用闭包方式。</p> <p>修改方案：将路由的具体实现放到控制器中来实现。</p> <h3>2. [Exception] Serialization of 'Closure' is not allowed.</h3> <p>在运行 php artisan route:cache 命令时报这个错误。</p> <p>原因：路由文件中定义了重复的路由。</p> <p>修改方案：排查路由文件中的重复路由并修改。尤其要注意 resource 方法很可能导致与其方法重复。</p> <h3>3. [RuntimeException] Invalid filename provided.</h3> <p>在运行 php artisan optimize --force 命名时报这个错误。</p> <p>原因：在加载需要编译的类时没有找到相应的文件。5.2 版本的 vendor/laravel/framework/src/Illuminate/Foundation/Console/Optimize/config.php 中定义了要编译的文件路径，但不知道为什么 /vendor/laravel/framework/src/Illuminate/Database/Eloquent/ActiveRecords.php 没有找到，所以报了这个错误。</p> <p>修改方案：暂时注释掉了以上 config.php 中的 ../ActiveRecords.php 一行。</p> <h3>4. InvalidArgumentException in FileViewFinder.php line 137: View [welcome] not found.</h3> <p>在运行 php artisan config:cache 之后，浏览器上访问 Laravel 应用程序欢迎页报这个错误。</p> <p>原因：Laravel 应用程序服务器是通过 Homestead 在虚拟机上搭建的。而这个命令我是在虚拟机之外运行的，导致生成的 config.php 中的路径是本机路径，而不是虚拟机上的路径。所以无法找到视图文件。</p> <p>修改方案：ssh 到虚拟机内部运行该命令。</p> <h2>0x04 实践技巧</h2> <p>坑也踩了，测试也做过了。这里针对这次经历做个实践技巧的简单总结。</p> <h3>1. 有效的 Laravel 应用程序优化技巧</h3> <ol> <li>关闭应用debug app.debug=false</li> <li>缓存配置信息 php artisan config:cache</li> <li>缓存路由信息 php artisan router:cache</li> <li>类映射加载优化 php artisan optimize （包含自动加载优化 composer dumpautoload ）</li> <li>根据需要只加载必要的中间件</li> <li>使用即时编译器（JIT），如：HHVM、OPcache</li> </ol> <h3>2. 编写代码时注意事项</h3> <ol> <li>路由的具体实现放到控制器中。</li> <li>不定义重复的路由，尤其注意 resouce 方法。</li> <li>弄清各中间件的作用，删除不必要的中间件引用。</li> </ol> <h2>0x06 下一步</h2> <p>以上的调优技巧及编码注意事项主要针对框架本身，在真正的业务逻辑编码中有很多具体的优化技巧，在此没有讨论。</p> <p>后续的优化重点将会放在具体编码实践上：</p> <ol> <li>使用 Memcached 来存储会话 config/session.php</li> <li>使用专业的缓存驱动器</li> <li>数据库请求优化</li> <li>为数据集书写缓存逻辑</li> <li>前端资源合并 Elixir</li> </ol> <h2>0x07 写在最后</h2> <p>网上看到很多框架性能对比的文章与争论，也看到很多简单贴出了数据。这些都不足以窥探真实的情况，所以有了我们这次的实践，并在过程中做了详实的记录。在各位读者实践过程中提供参考、比较、反思之用。对于这次实践有疑问的读者，也欢迎提出问题和意见。</p> <p>不多说了，要学习更多技术干货，请关注微信公众号：up2048。</p> <p>- EOF -</p> <p> </p> <p>来自：https://segmentfault.com/a/1190000011569012</p> <p> </p>