这是一个创建于 2670 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
yangyao 2017-07-17 15:14:23 +08:00
等你业务发展到一定阶段，composer 依赖逐渐增多的时候，性能差距就不那么明显了。
|
 |
2
jhdxr 2017-07-17 15:39:51 +08:00
1. 这个 benchmark 是基于 default configuration 的，其中只有 laravel 是默认开启 session 的；
2. 哪怕把 laravel 的 session 关掉，性能应该（因为我没有进行实际的测试，只是推测）也是不如 phalcon 的，因为 laravel 是用 php 写的，而 Phalcon 作为一个扩展是 C ； 3. 估算一下你的高并发的项目的峰值有多少，分到每台机器上又有多少，然后对比下那个 benchmark，也许你就会觉得其实高并发也没什么了； 4. 找一个你手头的代表作，分析下其中 PHP 代码执行、数据库调用、其他内部接口调用等分别耗时多少，也许你就会觉得框架本身的消耗差的并不是那么多了； 5. 如果你供职于 facebook，请无视我以上说的所有内容。（ btw，尽管 php7 在性能上赶上 /超过了 HHVM，但没有 HHVM 这个竞争对手，很可能 PHP7 在性能上根本不会有如此大的提升） |
 |
3
jarlyyn 2017-07-17 17:02:18 +08:00
说句可能不爱听的。
既然你选择在这个部分用 php。 那说明你这个部分并发并没有那么重要。 |
 |
7
Miy4mori 2017-07-17 18:57:12 +08:00 via iPhone
怕不是只有 yaf 可以满足你的要求
|
|
8
jarlyyn 2017-07-17 19:11:57 +08:00
把核心功能 换个其他的高并发语言比如 go 做个接口？
|
 |
9
zjsxwc 2017-07-17 19:18:10 +08:00
瓶颈在 io
|
 |
10
firefox12 2017-07-17 19:23:44 +08:00 via iPhone
1700 的 qps. 也不需要太关注什么语言
|
 |
12
troycheng 2017-07-18 11:18:13 +08:00
高并发不是目的，脱离场景的高并发没什么意义（除了单独压测框架性能）。峰值 1700，用 PHP，接口里稍微有点业务逻辑，单机就够呛能撑住。
|
 |
13
gclove 2017-07-18 13:29:10 +08:00
现在的服务器, 性能完全不在语言上
这个测试毫无任何意义, 我觉得(你读过它的代码吗) 它没有连接数据库 明显 Laravel 慢的原因是 比其它框架注入了更多的变量和方法, 比如你可以轻易的读取 session cache redis mysql cookie file 等等. |
|
14
gclove 2017-07-18 13:30:57 +08:00
当然事实上 phalcon 确实是比较快的
你觉得瓶颈在这里的话, 也可以用 Phalcon |
 |
15
cccoco123 2017-07-18 17:32:20 +08:00
异步协程框架,基于 swoole 特性实现了，SOA 服务化调用，支持并行、串行调用。支持异步日志,异步文件读写,异步 Mysql,异步 Redis,Mysql,Redis 连接池。
github.com/fucongcong/Group-Co |
|
18
cccoco123 2017-07-19 17:01:16 +08:00
@sagaxu 协程配合异步可以解决并发问题。而 php 本身更适合写业务。并不是因为要协程，就去用 go。 再说了 PHP 的协程也不难~
|
 |
19
sagaxu 2017-07-19 17:52:30 +08:00
@cccoco123 Go 也挺适合写业务的，map 和 array 都内置了，多态也有，也不用操心内存，web 周边设施比如 json/http 之类的也都内置了，近一两年从 PHP 转 Go 的不少。
PHP 的协程不难，但是麻烦，要折腾 swoole 2.0，如果在协程里调用了阻塞的 C 扩展，结果会如何？而且 swoole 的文档那么简陋，用户基数又远不如 Go 那么大，出问题的几率和解决问题的成本都高于 Go。PHP 的协程要好用，可能需要再等个三到五年，把 swoole 像 fpm 那样合并到 php 官方版本里去。按照现在用户的需求，swoole 才是 PHP 的未来，FPM 跟不上时代了。 |
 |
20
aksoft 2017-07-25 09:06:23 +08:00
你这个什么语言都不行，只能用 c
|
 |
21
Fireflyi 2017-07-29 23:07:32 +08:00
13 楼说的对， 还有看你装逼装的挺热乎不想打断你，1700qps 你单机器跑？你跑一个看看，高并发不可能考虑用 laravel，瓶颈主要也不再框架，没什么实战不要动不动就是高并发怎么怎么，说一句话至少 3 处地方看出你在瞎装逼
|
 |
22
hhxsv5 2018-01-31 16:27:59 +08:00
Laravel 确实慢，Lumen 虽说是精简版，但也不能匹敌 Golang 内置的 http 服务器。
如果历史项目是 Laravel 或 Lumen，想要快速提升性能，建议通过 Swoole 来加速，这是我目前在造的轮子，LaravelS github.com/hhxsv5/laravel-s 有兴趣可以尝试下。 |
|
23
hhxsv5 2018-01-31 16:31:07 +08:00
我们公司业务重度依赖 Laravel，服务化重度依赖 Lumen，不管怎么调优，FPM 下一个 Hello world 也要耗个 100 来毫秒。不能推到重做，这不现实，所以搞了 LaravelS。
|
Select Language