高并发追求性能的前提下,有必要把 Laravel 项目转换为 Lumen 么?

现在也算是tp转laravel的一个过渡期,所以优化方面还毫无经验,最近的一个写的一个高并发的的api被老大吐槽了,说40核的cpu也承受不了3000的并发,所以现在面临一个框架调优的问题,目前项目数据库查询量很少,主要是redis的操作,无session,所以现在调优有没有必要代码迁移到lumen上面?还是只需要在laravel上优化就行了?

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
最佳答案

我建议的优化路线是,先结合 laravel-s 让 laravel 跑在 swoole 上,如果并发还不能达到要求再考虑迁移框架。

40 核 cpu 并不能明显提升 laravel 的并发能力,laravel 的性能瓶颈在于数量众多的文件引用,反映到系统上就是磁盘 I/O 能力。

另外,从 laravel 迁移到 lumen 并非易事,有很大一块开箱即用的工具 lumen 并不包含。

可以参考

4年前 评论
Double-Jin 4年前
poker_face (楼主) 4年前
Tsukasa_Kanzaki (作者) 4年前
皮皮强 4年前
讨论数量: 15

我建议的优化路线是,先结合 laravel-s 让 laravel 跑在 swoole 上,如果并发还不能达到要求再考虑迁移框架。

40 核 cpu 并不能明显提升 laravel 的并发能力,laravel 的性能瓶颈在于数量众多的文件引用,反映到系统上就是磁盘 I/O 能力。

另外,从 laravel 迁移到 lumen 并非易事,有很大一块开箱即用的工具 lumen 并不包含。

可以参考

4年前 评论
Double-Jin 4年前
poker_face (楼主) 4年前
Tsukasa_Kanzaki (作者) 4年前
皮皮强 4年前

我不赞成换框架。至少以目前的社区来看,不赞成换 Lumen。

说点题外话。在核心数量接近某个阈值之后,加核心并不能显著提升性能,这是一个常识。40 核我认为已经很高了,是时候考虑其他因素或是负载均衡了。

4年前 评论

没必要换,享受laravel 强大生态的代价就最直观的访问体验。laravel 项目优化会有瓶颈,当你优化到一定程度甚至堆硬件配置都无法解决你的问题的时候,你应该考虑下更换下api接口框架。从laravel 到lumen 的性能提升显然不值得你去这样做。就像一楼说的 laravel-S 就是最好的解决方案,如果 40 cup 加上laravel-s 并且还不能解决问题的话我建议贵公司换个程序员

4年前 评论
poker_face (楼主) 4年前

laravel-s 性能提升也不明显,最明显的是采用hyperf等swoole协程框架,只有redis操作的话,协程优势不要太明显,可以压测试一下

4年前 评论

即要求高并发也要高性能,这不是PHP太擅长的时; 这块Java 和golang 更合适吧

4年前 评论

Lumen提升不大的,50步笑百步

4年前 评论

你的步骤有问题

你应该分析你的系统现在的短板在哪里,哪些地方能用最小的代价换取最大的效益。laravel切换lumen不是无缝切换的,可能换了非但没有让性能提升还出现了bug。

还有一点希望你能明白,论坛这里你大概率不会找到答案。因为最清楚你的系统的人,就是你这边的开发人员。你最好是去了解一下支撑高并发系统的一个大概思路,然后再针对你的项目去逐步优化。

4年前 评论
poker_face (楼主) 4年前
s51983 4年前
L学习不停 (作者) 4年前

项目如果不大的话可以用Yii试试。

4年前 评论
农村闲散劳动力

可以把高性能需求的服务转移到新框架, 建议hyperf

4年前 评论

40核的CPU都不支持到3000的并发量,这显然不是简单换框架就能解决的问题。你得看看你的并发起不来是具体因为什么原因导致的,比如IO 数据库连接 Nginx配置 系统核心配置等等。

4年前 评论

要做高并发,换成golang 肯定是最佳的选择

4年前 评论

说一下我自己的建议,Laravel启动的东西非常的多,换Lumen其实也没啥区别。主要的原因在于你加载的东西需要优化。

  1. 服务器环境,如果使用了多个核心,需要适当的调整一下php-fpm的配置,常见的lnmpa部署方案其实并发应该不至于这么差。强烈建议认真检查一下服务器上的nginx,php,apache,mysql等配置文件!!
  2. 非常不推荐Laravel-s,这个项目是一个个人开发项目,bug多于优化效果,不建议使用
  3. 适当的开启缓存,包括laravel的缓存,composer自动加载的优化,以及Opcache 或者hhvm等对代码的缓存,当然redis之类的对数据的缓存必不可少。
  4. 检查问题瓶颈是否出现在数据库,对表结构进行优化,比如大量的select * 表关联的使用。
  5. 至于评论区说的io啥的,我不是很认同,因为题主的5000并发都扛不住,性能表现实在太差,可以htop看一下系统占用,但是个人判断问题出在上面的步骤概率更大。
  6. 上面的操作后并发仍然达不到要求,建议修改laravel的服务提供者,去掉不必要的加载项,理论上正确的配置过后,单机并发至少上万是没问题的(实际会受业务代码影响)
4年前 评论
Double-Jin 4年前
皮皮强 (作者) 4年前
皮皮强 (作者) 4年前
Double-Jin 4年前
皮皮强 (作者) 4年前

我想到一个问题,3000并发,你们的APP得有多少的访问量?如果有这么多的访问量,还在乎一台WEB机器的成本? 再者难道,WEB机器不应该都是那个4核4G的多机器么?你们难道不怕一台机器挂了,这么大的量都不能访问。

如果要追求效率,那就不要用框架,纯文件单独写最快。感觉你们这个老大有点不懂装B,其实完全没有大项目的经验。

当然了,像QQ,taobao这种另外说,因为这个WEB机器提升还是可以节约很多成本的

4年前 评论
游离不2

@农村闲散劳动力 不建议换 hyperf,因为不知道作者能维护到哪天,目前看来 laravel 是维护的比较好的。

4年前 评论
_杭城浪子 4年前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!