Laravel 性能问题始终难以释怀,求指点

似乎众所周知laravel的性能在诸多PHP开发者口中总是被诟病,本人不服实测了一下,发现最小MVC应用下Laravel比tp5,yii2慢2-3倍,在国内PHP圈好像特别重视性能,yii2和tp5都要在官网上宣传自己性能出众好像才符合套路,在企业级应用上yii更受青睐,淘宝途牛等都在用yii,不知道laravel有哪些大企业在用,还有就是性能问题会不会成为在国内推行的最大障碍

准备用laravel开发项目,但是说服不了自己,求各路大神指点,谢谢!@Summer

本帖已被设为精华帖!
本帖由 Summer 于 2年前 加精
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 28

时隔一年,看到题主今日还在此主题活动,作为将Lumen搬上生产环境的我谈谈我对此的看法。如果说的不好,希望大家对我这个后辈多点宽容。

不得不说,题主所说的情况是存在的。Laravel使用php-fpm比市场上某些框架显得性能"不够强劲"。
Laravel执行速度不及Yaf这样使用C语言框架;I/O模型也不如yii2 swoole2 Zan Framwork这样的swoole框架。这些框架存在且有人用,就有他们存在的道理~但是他们也要认清一个事实,Laravel是目前最受PHPer欢迎的框架。我们不快但是我们开发速度高效;我们并发不高,但是我们...,我们优雅啊!

file

使用世界上最好的语言最受欢迎的框架(自嘲),难道不应该有一种自豪感吗,为什么说服不了自己呢?不过这个主题已经是一年之前了,如果题主还没有选择好框架的话,正如之前的回答一样估计项目也早就凉了。

我回国毕业之后赶上了猎豹移动旗下的一个电商平台刚刚成立,于是就在这里开始了第一份工作,到现在也一年半了。你们在手机上安装的猎豹浏览器、猎豹清理大师、金山电池医生、万年历、百思不得姐等猎豹移动旗下的App中,都会带上我们的电商SDK。也就是你们平时在我们这里看到的商城以及卖鞋子、情趣用品的牛皮藓其实都是我们搞的(这里先和用过的朋友们说声不好意思)。我们对流量的承载能力、数据反回的时间是有高要求的。

file

我知道,稳定性、鲁棒性、性能的问题已经困扰了大家很久。PHP一直被诟病不稳定,相较Java而言抗不了高并发。我知道我一年半之前Java写的流计算服务在线上还跑得又稳又准;可是一个礼拜之前部署的PHP爬虫,我都不知道这个点进程是否还活着,是不是已经好几天没有执行了。

我们的流量到底有多少呢?这么说吧,单猎豹清理大师一个App,实际有1000多万日活(公司号称4000万),首页打开PV每天有1.5亿。而这些埋点都会通过HTTP请求到达我们的服务器。试问,有多少人敢说,你们的TP5Yii2能接住这样的请求?如果能接住,你们算一算一共要多少台机器?每个月要花多少钱?

那么PHP适合这种场景吗?答案是肯定的。这种IO密集型的案例,你换成其他任何语言,都会有瓶颈。最终,你的服务是会落地到机器上的,机器的瓶颈有CPU 内存 磁盘IO 带宽 最大端口数等。大多数情况,高IO操作第一个爆炸的一定是上行带宽。我们取个整,以1024qps为例,假设平均个Response为20KB。那么你所需要购买的带宽就是20MB。有兴趣的朋友大家可以查一下价格,但是我们用阿里云的LBS这个流量走的是内网,是不占用外网上行带宽的。这个的优化空间很小,毕竟那么多请求都需要拿到数据,我们是通过中间件对ETag来做判断,对拿过数据的同学直接做302 Not Modify的(我先立个flag,后续我会单独发文细讲)。

接下来我们来算一算内存,由于我生产环境的内存很充裕,我直接就给Nginx的buffer设置到了9个128Kb的区块,暂时没有超出buffer落盘的日志。这里假设每个请求最多最多使用1Mb,由于我们Laravel使用的是fpm,所以在我们所在的child进程中请求结束后,所有的内存占用会被清掉不用担心内存泄漏的问题,那满打满算内存使用量到不了2G。(如果你的应用不仅是IO密集型,还是计算密集型,那么你使用的内存也会是个瓶颈)

接下来就是CPU了,这是我们Laravel的弱项。每个请求我们都会重新加载一次我们的服务容器。但是对于Lumen来说,我们所所需加载的量已经比Laravel要少很多了。我试过在我的机器上(由于性价比和法务的原因,我选择了阿里云聚石塔8核8G),输出几个基本和一般复杂的运算,打满CPU且不报错的情况差不多能ab -c 100 -n 100000达到 1500-4000的量(该优化的都优化了)。这里lumen官网给出了Benchmark 1900的数据,我觉得较为中肯。

说了这么多,这里的qps也是千把个。那么怎么才能接住1.5亿每天的请求呢?答案就是只做自己擅长做的事。我直接上图吧

file

我们所有的并非需要返回值的请求(例如埋点)在nginx就已经通过syslog直接在内存里就送到了阿里云的logtail,返回结果也是把头部都清空了(还需要47b),根本不需要通过PHP的fpm。而真正是要获取到信息的API的请求(最大的一个返回值有670kb),在峰值情况也不到2000qps,且均从本机memcache服务中读取后Format到想要的格式,不经过数据库。

所以我们的机器配置只有两台8核8G做API(其中一台还兼任流处理),两台4核4G做log收集。平日里负载都在30%左右。

请多指教

与君共勉

Ryan

1年前 评论
leo
  1. 绝大多数项目活不过性能撑不住的那天(除非你的sql写太烂)
  2. 框架本身的性能达到瓶颈加机器就是了,可以无限横向扩展,又不是BAT级别的访问量,多一两台服务器成本高不了多少
2年前 评论

@leo 这个观点刚开始我是赞同的,不过现在我觉得仅仅只拿出这几条还不够。

不过我先针对楼主的情形直接说答案:你如果明确地知道你的项目是什么类型,包括明白一些细枝末节的东西的话,你与其担心这个,不如先把规划做好,否则你选择任何一个框架,最终结果都是跳入深渊。

我觉得讨论性能问题有很多限定条件,并不能说开发阶段不要担心,虽然大多数情形是这样的,即要不是瓶颈根本不在框架,要不就是加机器就很容易解决。但毕竟不能抛开项目本身不谈,所以各类因素往往很复杂,三言两语也说不清楚。

最大的决定因素就是,项目本身类型和使用对象。其次就是整个产品周期的安排以及运营方案。

不是所有项目都是依赖数据库的,根本不存在大量 IO 的系统比比皆是。亦或者频繁的计算和 IO 并存的。对于 IO 密集型应用,不去做优化,你拿什么语言,差距都不会十分明显的,这种情景解决方案就非常多了,根据需要选择,框架毕竟是给提供工具集的东西,因此或多或少都会提供一些简单有效常用的解决办法,如果没有提供,也只不过将由框架做的变成了由你做的罢了。

对于密集计算,这个和语言本身、框架的设计就有着相对而言比较紧密的关联了。Laravel 弱在其生命周期中参与的部分实在太多,调用堆栈之长,你会发现框架给的那些优化方案其实都是杯水车薪。虽然我在这里这么说,但不意味着你真的会遇得到,就算遇得到,那么你拿任何语言、框架你也都遇得到,只是恰好 Laravel 放大了这一切。具体优化方案和 IO 密集一样有很多,但都脱离了 Laravel 本身,因为这些解决方案,并不影响你是否使用 Laravel,不过这取决于你的基本功,如果你把代码写的很糟心,那么重构可能更好。

还有使用对象,项目使用对象决定了你开发的优先保障目标,面向外部人群和面向内部的系统思路可是不一样的,毕竟外部的不确定因素更多,说到这里你应该能明白。

最后,产品周期安排是你必须在开发初期选择框架时就要关注的,如果草草上线,作为负责的有态度的开发者,明明知道面向客户群体复杂且庞大、系统涉及关键节点及其庞杂,这时候你更应该选择一个你更为熟悉的框架,不应该被各类广告、宣传、以及自来水冲昏头脑,否则最终你会为你的一时爽买单。很显然我就是其中的一员,不过这样也逼着我背下了一半的 Laravel 源码,我现在已经可以做到默写 40% 的 Laravel 框架了,只要放出新特性描述我都可以做到自己先实现起。

总结,Laravel 的确是一个高效且优雅的框架,作为其重度使用者的我也觉得这个框架已经被神话了。如果你有足够的时间且理解你所开发的项目,真心推荐使用 Laravel 作为项目开发框架。但是,如果,就像我说的,如果你对项目做不到知根知底、PHP 基础不扎实、周期紧张、项目影响大,所有综合因素来判定后,慎重决定。如果你真的很希望使用且愿意为后果买单,像我这样愿意深入学习其优秀特性、思想,仔细阅读文档、源码,做到举一反三甚至能做到任意改造且升级自如,那么,你还会提出这种问题吗?

2年前 评论

以下两点我要指出。

  1. 不要轻易、任性、随意添加各种各样的 package ,特别是需要添加 provicder 的那种,捡最需要的来。
  2. 模型的 Observer 多的话,确实会影响框架启动速度,当前的项目有二三十个,影响10~40ms的启动速度(服务器配置不一样,影响不一样),这个没办法处理了。

上面这两条是我的项目确实存在的问题,并且确实对哪怕一个 hello world 的简单输出也要有影响,但是很难处理掉的。

其他的挺好的,laravel 对我们的项目的进度和开发的质量真的相比其它框架提高了很多。并且线上的 8核16G OPCache,影响不太大,项目现在有100多个表,业务密集型的应用,速度满足我们的需要,大部分页面和接口 200ms 以内。

最后,SQL 一定要处理好,这个可能永远是你们项目性能最大的瓶颈。 :swimmer:

laravel 开发起来挺嗨的,确实挺嗨的

2年前 评论
MrJing

项目的可维护性,是相对更加重要的。用框架损耗一点性能,来换取开发效率、可维护性是值得。至于优化性能,手段很多,一般找到性能瓶颈对其优化即可,而性能瓶颈一般不会是在框架上。
比如:用 Laravel 比用XX框架,框架多消耗了 50ms。但是你发现流量上来后,瓶颈是在 IO 上(比如数据库,服务器硬盘,网络 IO)。假如可能是 mysql 数据库查询就慢了 1s。这时候要引入缓存,就可以解决该阶段的问题。在实施方案时,发现用XX框架加缓存,代码写得乱七八糟,漏洞百出。而用 Laravel,花了很短的时间和精力就上了缓存功能,并且代码优雅,结构清晰,易于维护。那么,框架的优势就体现了。

实在“说服不了自己”哩,就不要勉强啦,开心最重要。

2年前 评论
leo
  1. 绝大多数项目活不过性能撑不住的那天(除非你的sql写太烂)
  2. 框架本身的性能达到瓶颈加机器就是了,可以无限横向扩展,又不是BAT级别的访问量,多一两台服务器成本高不了多少
2年前 评论

其实到没觉得国内的PHP圈真的多重视性能。
项目起步阶段性能也绝对不是第一参考因素,如果高效切入、节约时间并能约束好发展路线才是最重要的。至于性能,我觉不是你能在一开始就能想清楚的。
还有一点:烂代码和烂的结构设计,不合理的数据库使用方式带来的问题比框架本身的问题要大太多了。

2年前 评论
Summer

@leo Leo 哥已经说得很好。

以下个人观点,仅供参考。

作为「应用工程师」,性能的事情,永远不是问题,开发高效、趋势,才是要重点考虑的东西。

PHP 不也一直被人骂慢吗?相对于其他如 C/C++/Java 等语言框架,PHP 实在是太慢了。问问你自己,你为啥选择 PHP ? 不就是因为他的开发高效和趋势么。

2017 年,随着 PHP7 的出现,PHP 已经不慢了。这就是趋势的力量。

另外问一句,你觉得 https://laravel-china.org 慢吗?LC 就是构建在 Laravel 上的。

2年前 评论
chenyuanqi

laravel 是为艺术而生的框架,而 PHP 的高版本已然对性能做出了很大的进步。
之所以国内少有大企业使用 laravel,恐怕考虑的不只是性能,而更多的是开发成本吧~

2年前 评论

赞同楼上几位的观点,目前的阶段,性能不是首要考虑的因素,开发高效才是最重要的,性能不行,多加一台机器就搞定,开发效率慢,你得多招几个人才搞得定?可以想像多招一个人和多配置一台服务器,哪个成本更大?再说了,好好想想,你的项目能扛到性能爆表那一天吗?

2年前 评论

@chenyuanqi 以前是熟悉laravel的少,但是现在流行起来,熟悉的人也多了,以后用 laravel 的企业会越来越多,我这边的项目,果断转到 laravel 了,最近这一两个月都在给项目组的人培训 laravel ,大家上手都很快

2年前 评论

@leo 赞同leo的第一个观点!!!

2年前 评论

主流的PHP框架的性能都差不多,没觉得那个PHP框架性能有多拔尖。Laravel的高开发效率,良好的代码风格为项目的持续开发提供很好的保障。如果配合上 redis缓存 + 云存储(阿里OSS或者七牛存储) + 服务器上SSD硬盘 + 适当的优化,性能可以妥妥的!放心用吧

2年前 评论

@Summer 我觉得LC慢啊 如果用tp5可能快点

2年前 评论

性能无需担心,除非是一线的应用;
laravel的学习成本高,轮子多;是否会有这样的情况,项目中使用了某个轮子,若干时间后laravel升级了,但这个轮子和新版的laravel不兼容了,更糟的是轮子的作者已经不维护了。。那么自己升级轮子或者laravel不升级,是不是有一些尴尬?

2年前 评论
乔布斯隆

@benjy 商业项目考虑使用 LTS 版本

2年前 评论

以下两点我要指出。

  1. 不要轻易、任性、随意添加各种各样的 package ,特别是需要添加 provicder 的那种,捡最需要的来。
  2. 模型的 Observer 多的话,确实会影响框架启动速度,当前的项目有二三十个,影响10~40ms的启动速度(服务器配置不一样,影响不一样),这个没办法处理了。

上面这两条是我的项目确实存在的问题,并且确实对哪怕一个 hello world 的简单输出也要有影响,但是很难处理掉的。

其他的挺好的,laravel 对我们的项目的进度和开发的质量真的相比其它框架提高了很多。并且线上的 8核16G OPCache,影响不太大,项目现在有100多个表,业务密集型的应用,速度满足我们的需要,大部分页面和接口 200ms 以内。

最后,SQL 一定要处理好,这个可能永远是你们项目性能最大的瓶颈。 :swimmer:

laravel 开发起来挺嗨的,确实挺嗨的

2年前 评论
Chasers9527

https://segmentfault.com/a/119000000789411...

file

你可以试试啊 反正我是还没到达考虑性能问题的时候

2年前 评论
MrJing

项目的可维护性,是相对更加重要的。用框架损耗一点性能,来换取开发效率、可维护性是值得。至于优化性能,手段很多,一般找到性能瓶颈对其优化即可,而性能瓶颈一般不会是在框架上。
比如:用 Laravel 比用XX框架,框架多消耗了 50ms。但是你发现流量上来后,瓶颈是在 IO 上(比如数据库,服务器硬盘,网络 IO)。假如可能是 mysql 数据库查询就慢了 1s。这时候要引入缓存,就可以解决该阶段的问题。在实施方案时,发现用XX框架加缓存,代码写得乱七八糟,漏洞百出。而用 Laravel,花了很短的时间和精力就上了缓存功能,并且代码优雅,结构清晰,易于维护。那么,框架的优势就体现了。

实在“说服不了自己”哩,就不要勉强啦,开心最重要。

2年前 评论

@leo 这个观点刚开始我是赞同的,不过现在我觉得仅仅只拿出这几条还不够。

不过我先针对楼主的情形直接说答案:你如果明确地知道你的项目是什么类型,包括明白一些细枝末节的东西的话,你与其担心这个,不如先把规划做好,否则你选择任何一个框架,最终结果都是跳入深渊。

我觉得讨论性能问题有很多限定条件,并不能说开发阶段不要担心,虽然大多数情形是这样的,即要不是瓶颈根本不在框架,要不就是加机器就很容易解决。但毕竟不能抛开项目本身不谈,所以各类因素往往很复杂,三言两语也说不清楚。

最大的决定因素就是,项目本身类型和使用对象。其次就是整个产品周期的安排以及运营方案。

不是所有项目都是依赖数据库的,根本不存在大量 IO 的系统比比皆是。亦或者频繁的计算和 IO 并存的。对于 IO 密集型应用,不去做优化,你拿什么语言,差距都不会十分明显的,这种情景解决方案就非常多了,根据需要选择,框架毕竟是给提供工具集的东西,因此或多或少都会提供一些简单有效常用的解决办法,如果没有提供,也只不过将由框架做的变成了由你做的罢了。

对于密集计算,这个和语言本身、框架的设计就有着相对而言比较紧密的关联了。Laravel 弱在其生命周期中参与的部分实在太多,调用堆栈之长,你会发现框架给的那些优化方案其实都是杯水车薪。虽然我在这里这么说,但不意味着你真的会遇得到,就算遇得到,那么你拿任何语言、框架你也都遇得到,只是恰好 Laravel 放大了这一切。具体优化方案和 IO 密集一样有很多,但都脱离了 Laravel 本身,因为这些解决方案,并不影响你是否使用 Laravel,不过这取决于你的基本功,如果你把代码写的很糟心,那么重构可能更好。

还有使用对象,项目使用对象决定了你开发的优先保障目标,面向外部人群和面向内部的系统思路可是不一样的,毕竟外部的不确定因素更多,说到这里你应该能明白。

最后,产品周期安排是你必须在开发初期选择框架时就要关注的,如果草草上线,作为负责的有态度的开发者,明明知道面向客户群体复杂且庞大、系统涉及关键节点及其庞杂,这时候你更应该选择一个你更为熟悉的框架,不应该被各类广告、宣传、以及自来水冲昏头脑,否则最终你会为你的一时爽买单。很显然我就是其中的一员,不过这样也逼着我背下了一半的 Laravel 源码,我现在已经可以做到默写 40% 的 Laravel 框架了,只要放出新特性描述我都可以做到自己先实现起。

总结,Laravel 的确是一个高效且优雅的框架,作为其重度使用者的我也觉得这个框架已经被神话了。如果你有足够的时间且理解你所开发的项目,真心推荐使用 Laravel 作为项目开发框架。但是,如果,就像我说的,如果你对项目做不到知根知底、PHP 基础不扎实、周期紧张、项目影响大,所有综合因素来判定后,慎重决定。如果你真的很希望使用且愿意为后果买单,像我这样愿意深入学习其优秀特性、思想,仔细阅读文档、源码,做到举一反三甚至能做到任意改造且升级自如,那么,你还会提出这种问题吗?

2年前 评论

再补一句,什么框架语言,真的不重要,人才是最重要的。

2年前 评论

感谢大家的热情解答,谢谢各位!

2年前 评论

Taylor 才写了一篇关于各框架性能比较的 文章。可是看起来Laravel也没啥性能问题 :no_mouth:。前面各位大牛都已将说的很明白了,任何问题都必须针对特定的技术场景。如果 我现在目标就是做一个 BAT 级别的产品,那我都不会考虑用 php,如果我只是快速进行产品开发,那 Laravel 必定是我第一首选。任何问题请留到可能会出现的那天再去考虑怎么解决,过早的优化是万恶之源!

无比赞同Taylor的观点 :raised_hands:

file

2年前 评论
jasonchang

@yyyang laravel 确实慢,但是不至于差很多,laravel 节省出来的开发成本,远比增加服务器大。
还有几个基本问题

  1. php7 用了吗
  2. opcache 开了吗
  3. optimaize 了吗
2年前 评论

评论中众多兄台的意见都说的差不多了,这里我只说说自己多年来的切身体会。我的经验是,除非你所在的公司或参与的项目很牛逼,否则的话,你写的代码难听点说不会存在的如你所想的那么久,就算真有那么久,届时你也未必还留在现在的岗位上了。因此,什么性能之类在某种意义上说根本就是“关你鸟事”,你要面对的只是如何快速的交付任务和下班,以及应接不暇的各种狗屎新功能,在这种环境下,一个好维护的代码要胜过跑得快的代码。

退一步说,你是有志青年,想要写出一个性能出众的程序,我觉得追求这个层次的人应该不会只依靠框架了,具体的就多了,我也说不清楚。

一个人从有激情到麻木妥协,很多时候并不是因为自己的沉沦,而是外界环境逼你如此,没有选择。有空玩玩一个独立游戏《Inside》,之后你会有同样的感悟。

2年前 评论

@wyg27 评论都看了看 看到你说的Inside,确实很出众的东西,当时可是费脑经啊,几个人一起想各种方法

1年前 评论

时隔一年,看到题主今日还在此主题活动,作为将Lumen搬上生产环境的我谈谈我对此的看法。如果说的不好,希望大家对我这个后辈多点宽容。

不得不说,题主所说的情况是存在的。Laravel使用php-fpm比市场上某些框架显得性能"不够强劲"。
Laravel执行速度不及Yaf这样使用C语言框架;I/O模型也不如yii2 swoole2 Zan Framwork这样的swoole框架。这些框架存在且有人用,就有他们存在的道理~但是他们也要认清一个事实,Laravel是目前最受PHPer欢迎的框架。我们不快但是我们开发速度高效;我们并发不高,但是我们...,我们优雅啊!

file

使用世界上最好的语言最受欢迎的框架(自嘲),难道不应该有一种自豪感吗,为什么说服不了自己呢?不过这个主题已经是一年之前了,如果题主还没有选择好框架的话,正如之前的回答一样估计项目也早就凉了。

我回国毕业之后赶上了猎豹移动旗下的一个电商平台刚刚成立,于是就在这里开始了第一份工作,到现在也一年半了。你们在手机上安装的猎豹浏览器、猎豹清理大师、金山电池医生、万年历、百思不得姐等猎豹移动旗下的App中,都会带上我们的电商SDK。也就是你们平时在我们这里看到的商城以及卖鞋子、情趣用品的牛皮藓其实都是我们搞的(这里先和用过的朋友们说声不好意思)。我们对流量的承载能力、数据反回的时间是有高要求的。

file

我知道,稳定性、鲁棒性、性能的问题已经困扰了大家很久。PHP一直被诟病不稳定,相较Java而言抗不了高并发。我知道我一年半之前Java写的流计算服务在线上还跑得又稳又准;可是一个礼拜之前部署的PHP爬虫,我都不知道这个点进程是否还活着,是不是已经好几天没有执行了。

我们的流量到底有多少呢?这么说吧,单猎豹清理大师一个App,实际有1000多万日活(公司号称4000万),首页打开PV每天有1.5亿。而这些埋点都会通过HTTP请求到达我们的服务器。试问,有多少人敢说,你们的TP5Yii2能接住这样的请求?如果能接住,你们算一算一共要多少台机器?每个月要花多少钱?

那么PHP适合这种场景吗?答案是肯定的。这种IO密集型的案例,你换成其他任何语言,都会有瓶颈。最终,你的服务是会落地到机器上的,机器的瓶颈有CPU 内存 磁盘IO 带宽 最大端口数等。大多数情况,高IO操作第一个爆炸的一定是上行带宽。我们取个整,以1024qps为例,假设平均个Response为20KB。那么你所需要购买的带宽就是20MB。有兴趣的朋友大家可以查一下价格,但是我们用阿里云的LBS这个流量走的是内网,是不占用外网上行带宽的。这个的优化空间很小,毕竟那么多请求都需要拿到数据,我们是通过中间件对ETag来做判断,对拿过数据的同学直接做302 Not Modify的(我先立个flag,后续我会单独发文细讲)。

接下来我们来算一算内存,由于我生产环境的内存很充裕,我直接就给Nginx的buffer设置到了9个128Kb的区块,暂时没有超出buffer落盘的日志。这里假设每个请求最多最多使用1Mb,由于我们Laravel使用的是fpm,所以在我们所在的child进程中请求结束后,所有的内存占用会被清掉不用担心内存泄漏的问题,那满打满算内存使用量到不了2G。(如果你的应用不仅是IO密集型,还是计算密集型,那么你使用的内存也会是个瓶颈)

接下来就是CPU了,这是我们Laravel的弱项。每个请求我们都会重新加载一次我们的服务容器。但是对于Lumen来说,我们所所需加载的量已经比Laravel要少很多了。我试过在我的机器上(由于性价比和法务的原因,我选择了阿里云聚石塔8核8G),输出几个基本和一般复杂的运算,打满CPU且不报错的情况差不多能ab -c 100 -n 100000达到 1500-4000的量(该优化的都优化了)。这里lumen官网给出了Benchmark 1900的数据,我觉得较为中肯。

说了这么多,这里的qps也是千把个。那么怎么才能接住1.5亿每天的请求呢?答案就是只做自己擅长做的事。我直接上图吧

file

我们所有的并非需要返回值的请求(例如埋点)在nginx就已经通过syslog直接在内存里就送到了阿里云的logtail,返回结果也是把头部都清空了(还需要47b),根本不需要通过PHP的fpm。而真正是要获取到信息的API的请求(最大的一个返回值有670kb),在峰值情况也不到2000qps,且均从本机memcache服务中读取后Format到想要的格式,不经过数据库。

所以我们的机器配置只有两台8核8G做API(其中一台还兼任流处理),两台4核4G做log收集。平日里负载都在30%左右。

请多指教

与君共勉

Ryan

1年前 评论

能不能有编辑功能.@Summer
HTTP CODE 304写成 302 了
好丢脸 >///<

1年前 评论
xianyunyehe

PHP开发效率高,当你遇到所说的性能的瓶颈的时候,说明公司业务已经不错了。

这个时候,架构肯定是另外一套了,团队可能会选择静态语言重构,所以不要太担心性能。

11个月前 评论

@RyanFeng 兄弟,真不容易,写了这么多。

10个月前 评论

@Summer 刷新本页面每次都要2秒以上,还敢说不慢

7个月前 评论

公司的战略粗浅的可以分为以下几个阶段:尝试期;成型期;扩张期;高效执行期。
在尝试期试水时长,项目要快速上线,抢占市场,用php开发,可缩短研发周期,部署更是爽的一匹。但是一旦到后面几个阶段,公司如果还能可续持增长,那么面对的就是高性能的程序+低成本的基础设施。不然成本高居不下,就知道堆机器,公司收入降低,哪来的毛爷爷发福利呢,我直肠子,我就喜欢发奖金~~ :joy:

2个月前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!

社区文档:

将托管在 packagist.org 和 github.com 的扩展包使用国内 CDN 加速
GitHub Laravel 扩展包 TOP 250
速查表方便快速查询框架功能,支持手机访问,支持中英文版本
Laravel 中文文档,由社区用户翻译和维护,将会保持一直更新
此文档的目的,就是为了提高技术团队的凝聚力、一致性和生产效率。
开发环境的部署,开发者工具的选择,适用于 Mac 和 Windows。
浓缩过后的精华
Laravel Nova 后台管理面板文档的中文翻译
Lumen 中文文档,由社区用户翻译和维护,将会保持一直更新
Laravel 下知名扩展包 Dingo API 的中文文档,Laravel API 开发必知必会