PHP 7.2 Beta 的 Benchmarks 测试:PHP 仍然越来越快 - 开源中国社区
PHP 7.2 Beta 的 Benchmarks 测试:PHP 仍然越来越快
局长 2017年07月31日

PHP 7.2 Beta 的 Benchmarks 测试:PHP 仍然越来越快

局长 局长 发布于2017年07月31日 收藏 7

有免费的MySQL,为什么还要买? >>>  

PHP 7.2 Beta 1 已于上周发布,预计将于 11 月发布正式版。

PHP 7.2 Beta 1 实现了更多的 Sodium 扩展,针对现代和易于使用的加密、改进 opcache、无效 UTF-8 数据更好的 JSON 解码这些方面,以及自 PHP 7.1 以来的许多错误修复和其他改进。最新的版本和更多的细节可以通过 PHP.net 找到。

测试的系统信息

先看看 PHP 7.2 Beta 1 与 PHP 7.1.7, 7.0.21, 和 5.6.31 的性能对比

可以明显看到,在性能测试方面,从 PHP 5.6 到 PHP 7.0,性能有了显著的增长。不过这并没什么值得惊喜的,但看到使用 PHP 7.2 Beta 1 也有了很大的性能提升这倒是有点意想不到。由上图可看到,PHP 7.2 目前的运行速度比 PHP 7.1 快了 13%,比 PHP 7.0 快了 20%,相比 PHP 5.6,则比它快了差不多 2.6 倍。

Phoronix 测试套件的自我测试显示,PHP 7.2 越来越快了,与 PHP 7.1.7 相比,将自我测试的时间缩短了 4 秒,尽管与 PHP 5.6 到 7.0 的转变相比还有较大差距,但仍节省了一点时间。

使用大量的 PHP math、DOM 对象使用以生成 SVG 图像的渲染测试在 PHP 7.2 中也是仍稍快一些。

总的来说,PHP 7 在继续朝着正确的方向改进着,除了这些适度的性能提升,还有其他方面的改进。

来自:www.phoronix.com

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:PHP 7.2 Beta 的 Benchmarks 测试:PHP 仍然越来越快
分享
评论(41)
精彩评论
18
PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。
6
PHP 请停止你的脚步
4

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?

引用来自“orpherus”的评论

JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。

引用来自“eechen”的评论

使用FreeBSD和Erlang技术的WhatsApp照样能把亿级别的即时通讯用户支撑起来.
所以,为什么一定非得上你所谓的CPP或者Java呢?
难道PHP+Swoole就一定不行么?
是你测试过发现不行呢,还只是你认为不行?
如果PHP有那么好,swoole的东家干嘛不用最好的语言写网关?擅长这个领域的语言很多,erlang和golang都可以,JAVA也可以,PHP成功case相对比较少,原因是什么就不得而知了。
3
有PHP的地方就有撕逼
3

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。
https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.
最新评论
0

引用来自“kernel64”的评论

好快好害怕.

“可以通过 PHP.net 找到。”为毛是.net呢?用上dotnet了?

引用来自“阿多”的评论

能把域名.net和微软.NET联系起来, 也是神奇啊...
PHP这么强大,不是可以兼容dotnet的吗?
0
:smile: 又怼上了
0

引用来自“老牛拉货车”的评论

eechen 竟然没出现?

引用来自“金三胖”的评论

@老牛拉货车 eechen还有5秒到达战场,请做好准备
果然,好激烈啊,战斗已经呈现白热化了
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?

引用来自“orpherus”的评论

JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。

引用来自“eechen”的评论

使用FreeBSD和Erlang技术的WhatsApp照样能把亿级别的即时通讯用户支撑起来.
所以,为什么一定非得上你所谓的CPP或者Java呢?
难道PHP+Swoole就一定不行么?
是你测试过发现不行呢,还只是你认为不行?

引用来自“orpherus”的评论

如果PHP有那么好,swoole的东家干嘛不用最好的语言写网关?擅长这个领域的语言很多,erlang和golang都可以,JAVA也可以,PHP成功case相对比较少,原因是什么就不得而知了。

引用来自“eechen”的评论

少扯淡,少吹嘘吧,现在Web即时通讯这块,最火的不是Erlang,不是Golang,更不是Java,而是Node.js,难道你不知道说起WebIM就言必谈Socket.IO么?所以,你所谓的高大上,在Node.js Socket.IO和PHP Swoole这些方案面前,卵用没有,人家Socket.IO和Swoole,写起IM来就是快,几行代码就能实现广播推送,而且性能还不赖,这就是事实,不如你Java来对比下:
浏览器:
var ws = new WebSocket("ws://localhost:8080");
ws.onmessage = function(e) {
  var msg = JSON.parse(e.data);
  console.log(msg.fd);
  console.log(msg.data);
  console.log(msg.time);
}
服务器:
$ws = new Swoole\Websocket\Server('localhost', 8080);
$ws->on('message', function($ws, $frame) {
  // 消息格式可以用JSON
  $msg = json_encode(array(
    'fd' => $frame->fd,
    'data' => $frame->data,
    'time' => date('Y年m月d日 H:i:s')
  ));
  // 【服务器推】推送消息给所有客户端
  foreach($ws->connections as $fd) { $ws->push($fd, $msg); }
});

引用来自“orpherus”的评论

来一个Java的broadcast,序列化和反序列化是自动的,不需要手动JSON,几行代码直接整合进普通的spring站点

@MessageMapping("/hello")
@SendTo("/topic/greetings")
public Greeting greeting(HelloMessage message) throws Exception {
return new Greeting("Hello, " + message.getName() + "!");
}

完整的带HTML和JS的代码也没几行
https://spring.io/guides/gs/messaging-stomp-websocket/

nodejs做webim方便,那就用啊,又不是非要用Java或者Go的,我又不是XX语言的粉丝,我是墙头草,哪个方便我就用哪个,我手头一个小项目用了7种语言,PHP也是其中一种,各取所长就行了。
你给的那个Java示例,也敢说没几行么?
我给的那个Swoole示例,不依赖任何框架,真的就是那么几行代码,就能跑起来.
如果再监听onrequest事件,那就连HTTP长轮询也支持了.
可以说,Swoole对代码的侵入性非常小,完全是你调用Swoole,而不是框架调用你.
同时,Swoole的封装又十分简单高效,可以说,完全继承了PHP少写多做的优势,这点连Socket.IO都没法比.
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?

引用来自“orpherus”的评论

JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。

引用来自“eechen”的评论

使用FreeBSD和Erlang技术的WhatsApp照样能把亿级别的即时通讯用户支撑起来.
所以,为什么一定非得上你所谓的CPP或者Java呢?
难道PHP+Swoole就一定不行么?
是你测试过发现不行呢,还只是你认为不行?

引用来自“orpherus”的评论

如果PHP有那么好,swoole的东家干嘛不用最好的语言写网关?擅长这个领域的语言很多,erlang和golang都可以,JAVA也可以,PHP成功case相对比较少,原因是什么就不得而知了。

引用来自“eechen”的评论

少扯淡,少吹嘘吧,现在Web即时通讯这块,最火的不是Erlang,不是Golang,更不是Java,而是Node.js,难道你不知道说起WebIM就言必谈Socket.IO么?所以,你所谓的高大上,在Node.js Socket.IO和PHP Swoole这些方案面前,卵用没有,人家Socket.IO和Swoole,写起IM来就是快,几行代码就能实现广播推送,而且性能还不赖,这就是事实,不如你Java来对比下:
浏览器:
var ws = new WebSocket("ws://localhost:8080");
ws.onmessage = function(e) {
  var msg = JSON.parse(e.data);
  console.log(msg.fd);
  console.log(msg.data);
  console.log(msg.time);
}
服务器:
$ws = new Swoole\Websocket\Server('localhost', 8080);
$ws->on('message', function($ws, $frame) {
  // 消息格式可以用JSON
  $msg = json_encode(array(
    'fd' => $frame->fd,
    'data' => $frame->data,
    'time' => date('Y年m月d日 H:i:s')
  ));
  // 【服务器推】推送消息给所有客户端
  foreach($ws->connections as $fd) { $ws->push($fd, $msg); }
});
来一个Java的broadcast,序列化和反序列化是自动的,不需要手动JSON,几行代码直接整合进普通的spring站点

@MessageMapping("/hello")
@SendTo("/topic/greetings")
public Greeting greeting(HelloMessage message) throws Exception {
return new Greeting("Hello, " + message.getName() + "!");
}

完整的带HTML和JS的代码也没几行
https://spring.io/guides/gs/messaging-stomp-websocket/

nodejs做webim方便,那就用啊,又不是非要用Java或者Go的,我又不是XX语言的粉丝,我是墙头草,哪个方便我就用哪个,我手头一个小项目用了7种语言,PHP也是其中一种,各取所长就行了。
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?

引用来自“orpherus”的评论

JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。

引用来自“eechen”的评论

使用FreeBSD和Erlang技术的WhatsApp照样能把亿级别的即时通讯用户支撑起来.
所以,为什么一定非得上你所谓的CPP或者Java呢?
难道PHP+Swoole就一定不行么?
是你测试过发现不行呢,还只是你认为不行?

引用来自“orpherus”的评论

如果PHP有那么好,swoole的东家干嘛不用最好的语言写网关?擅长这个领域的语言很多,erlang和golang都可以,JAVA也可以,PHP成功case相对比较少,原因是什么就不得而知了。
少扯淡,少吹嘘吧,现在Web即时通讯这块,最火的不是Erlang,不是Golang,更不是Java,而是Node.js,难道你不知道说起WebIM就言必谈Socket.IO么?所以,你所谓的高大上,在Node.js Socket.IO和PHP Swoole这些方案面前,卵用没有,人家Socket.IO和Swoole,写起IM来就是快,几行代码就能实现广播推送,而且性能还不赖,这就是事实,不如你Java来对比下:
浏览器:
var ws = new WebSocket("ws://localhost:8080");
ws.onmessage = function(e) {
  var msg = JSON.parse(e.data);
  console.log(msg.fd);
  console.log(msg.data);
  console.log(msg.time);
}
服务器:
$ws = new Swoole\Websocket\Server('localhost', 8080);
$ws->on('message', function($ws, $frame) {
  // 消息格式可以用JSON
  $msg = json_encode(array(
    'fd' => $frame->fd,
    'data' => $frame->data,
    'time' => date('Y年m月d日 H:i:s')
  ));
  // 【服务器推】推送消息给所有客户端
  foreach($ws->connections as $fd) { $ws->push($fd, $msg); }
});
3
有PHP的地方就有撕逼
0
为什么总有人能挑起语言之争?存在即合理,php至今没有灭亡,还能占据语言榜单的前几名,自然说明他有过人之处,瞧不起的人我不知道你们是哪里来的底气?哈哈。Java和php各有所长,各有所短,能完美解决实际需求的才是最重要,对我们开发者来说这不也是梦寐以求的吗?
1

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“乌龟壳”的评论

netty表示强烈打脸nio,java这方面做得还不够好。
ps:我完全没兴趣讨论php在这方面的表现。

引用来自“orpherus”的评论

netty不也是oio + nio嘛
你看下netty的项目缘起,提了很多nio的历史问题,然后再看看native模块,种种都表明在追求极致上,netty在给java当前的情况擦屁股
0
宇宙最强语言Java不服!
0
4

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?

引用来自“orpherus”的评论

JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。

引用来自“eechen”的评论

使用FreeBSD和Erlang技术的WhatsApp照样能把亿级别的即时通讯用户支撑起来.
所以,为什么一定非得上你所谓的CPP或者Java呢?
难道PHP+Swoole就一定不行么?
是你测试过发现不行呢,还只是你认为不行?
如果PHP有那么好,swoole的东家干嘛不用最好的语言写网关?擅长这个领域的语言很多,erlang和golang都可以,JAVA也可以,PHP成功case相对比较少,原因是什么就不得而知了。
1

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?

引用来自“orpherus”的评论

JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。
使用FreeBSD和Erlang技术的WhatsApp照样能把亿级别的即时通讯用户支撑起来.
所以,为什么一定非得上你所谓的CPP或者Java呢?
难道PHP+Swoole就一定不行么?
是你测试过发现不行呢,还只是你认为不行?
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。

引用来自“eechen”的评论

Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?
JAVA有进程内共享的习惯性用法,比如说连接池,或者一些结构化数据,没法通过redis共享,所有的多进程方案都会有这个问题。不是要跟风大厂,而是大厂们不约而同的用Cpp和Java做后台服务,并非拍脑袋做的决定。Facebook是有PHP,但他们还有更多的服务是Cpp和Java,对他们而言PHP只是历史遗留。

swoole2虽然没发布,已经有一些项目已经用上了,迟早会取代现在的异步回调。
0
@orpherus
https://wiki.swoole.com/wiki/page/300.html
Swoole文档里写了:
max_request只能用于同步阻塞、无状态的请求响应式服务器程序
纯异步的Server不应当设置max_request
所以说,Swoole里的max_request,跟PHP-FPM里的差不多,都是为阻塞型服务准备的。
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients

引用来自“orpherus”的评论

你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。
Swoole的max_request同样是可选的东西,并不是必须配置的东西,
而且有总比没有好,毕竟是个好配置,问题来了,多线程的Java有么?

Swoole本来就不是为Windows设计,就像Redis,人家Redis官方根本就没出Windows,
你却非要拿Windows平台来说事,这不是蛋疼么?

Redis能共享socket连接和你所谓的线段树么?如果不能,然后你就说Redis是残废了么?呵呵.
JAVAer那么大口气,还用什么Redis,直接自己缓存就好了嘛.

之前一直以为Linux的open files最大值是65535,但其实可以更大.
所以你说的C1000K,理论上应该可行.

回调的写法是大多数异步实现的通病.
Swoole 2.0才支持协程,不过2.0还没有正式发布.

阿里前端用Node.js取代模板层的PHP,很正常么?前端肯定更喜欢JS了.
不过为什么一定要跟风大厂?
Facebook用HHVM,难道PHP开发者都要转投HHVM而弃用PHP7么?
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“eechen”的评论

我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients
你是说PHP只适合做web开发吗?如果做点非web的东西,用不用得到大量数值计算呢?

不知道swoole有task_max_request和max_request吗?官网这么写的“这个参数的主要作用是解决PHP进程内存溢出问题。PHP应用程序有缓慢的内存泄漏,但无法定位到具体原因、无法解决,可以通过设置max_request解决。”

swoole在windows下用的就是cygwin,而不是更加高效和native的IOCP,限制了在windows下的性能。

APC和swoole_table,只支持共享简单的数据结构,能共享socket连接吗?能共享自定义数据结构,比如线段树吗?

单机65535个ESTABLISHED连接就已经是极限? 呵呵,http://lmgtfy.com/?q=C1000K

swoole是可以异步,但是你觉得Java需要开2000线程的时候,异步合适吗?显然是异步已经不太方便的时候了,业务逻辑非常复杂的时候,异步写出来就是nodejs那样的callback hell。这种业务,swoole作者都不推荐使用异步回调,推荐了swoole的协程。

听说阿里的php也换成nodejs了,最近大厂们似乎不太待见PHP。
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?

引用来自“乌龟壳”的评论

netty表示强烈打脸nio,java这方面做得还不够好。
ps:我完全没兴趣讨论php在这方面的表现。
netty不也是oio + nio嘛
2

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?
我那个测试中主要包含时间戳获取,字符串拼接,字典生成这几个操作.
而这些操作,在Web开发中会被频繁使用,反观你那个素数生成,Web开发几时会用?

还有,别好像了,Swoole跟Cygwin毛线关系都没有.
只不过是如果使用Windows的开发者,想要在Windows上使用Swoole,那就可以在Cygwin里跑Swoole.
这个Swoole依赖Cygwin什么的八竿子打不着.
Swoole连libevent这些通用的异步库都不依赖,完全就是自己用epoll从底层搭起来.
还有,接收指定数量重启进程,这个动作是PHP-FPM支持的操作.
而PHP-CLI下的Swoole和WorkerMan这些,至少我没听说过有这个操作配置.

在Swoole异步编程的支持下,PHP根本不需要堆进程和线程,只需开CPU核心数的进程或线程数即可.
在PHP多进程间共享数据,如果不想用Redis,那就用PHP的APCu.
如果连APCu都不想用,那就用Swoole内置的swoole_table:
https://wiki.swoole.com/wiki/page/p-table.html
不知道,就别说PHP没有.
PHP是简单,但简单不等于就是弱鸡.

还有,你说的【单机实现1000万长连接】是什么鬼?单机65535个ESTABLISHED连接就已经是极限.
比如Redis客户端最大连接数默认也才1万个(C10K):
redis-cli config get maxclients
0

引用来自“喷子”的评论

PHP 7,请停止你的脚步,再快你就不是我们心目中本来的那个PHP了,毕竟java才是世界上最好的语言。

引用来自“orpherus”的评论

放心吧,动态类型语言,优化的难度远高于静态类型,引用计数型内存管理,throughput也不容易赶上tracing gc。在coroutine和cli常驻运行方面,PHP也才刚起步,能维持现在的地位已经不容易了。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
那么快就忘了上次我发的那个生成一个包含100万个元素的关联数组的测试了.
Java实现同样逻辑要比PHP7稍快的话,需要大量的内存,比如1个GB,而PHP只需82MB左右.
这个你自己都测试过,不用我说了吧.

什么叫PHP cli常驻刚起步?从PHP诞生开始,cli就支持常驻,何来刚起步之说?
就算说的是cli下的异步编程,那ReactPHP/WorkerMan/Swoole这些异步框架也出现好几年了.
还有,C实现的PHP Swoole的性能,我想Java的NIO极有可能比不过.

引用来自“orpherus”的评论

光生成100万数组没什么用,全测的C写的数组结构,不如测一下生成前100万个素数,更体现php代码的性能。php cli常驻,等哪天不用每接收n个请求就重启一个进程,就算成熟了。不要小看NIO,大家底下都是epoll,单机实现1000万长连接也不难,NIO在各个平台都是用最快那个API,swoole好像还在用cygwin这种低性能库。swoole还有很多事情不方便做,比如多个进程共享复杂的数据结构,比如需要做非常耗时的load操作,每个进程做一次代价太大了。2000个java线程只占用1G内存就够了,PHP开2000个进程试试?
netty表示强烈打脸nio,java这方面做得还不够好。
ps:我完全没兴趣讨论php在这方面的表现。
顶部