Swoole 1.9.17 发布,增加静态文件处理器 - 开源中国社区
Swoole 1.9.17 发布,增加静态文件处理器
matyhtf 2017年07月28日

Swoole 1.9.17 发布,增加静态文件处理器

matyhtf matyhtf 发布于2017年07月28日 收藏 11

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

PHP的异步、并行、高性能网络通信引擎 Swoole 已发布 1.9.17 版本。此版本增加了一个静态文件处理器,可以在 Swoole\Http\Server 中直接处理静态文件,而不需要 Nginx 服务器。另外 1.9.17 版本重构了 reload 特性,在异步模式下可支持安全的stop、reload、max_request

主要更新:

  • 异步模式支持安全的stop、reload、max_request

  • 增加HttpServer静态文件处理器,可配置document_root和enable_static_handler来启用

  • 增加SSL连接sendfile支持

  • 增加42个新的单元测试脚本

  • 修复HttpClient使用http_proxy代理设置时无法正常工作的问题

静态处理器:

$serv = new Swoole\Http\Server("127.0.0.1", 9502);

$serv->set([
    'enable_static_handler' => true,
    'document_root' => '/data/webroot/www.swoole.com/'
]);

$serv->on('Request', function($request, $response) {
    $response->end("<h1>Hello Swoole!</h1>");
});

$serv->start();

开启静态文件处理器后,浏览器访问 webroot 下的 js、css、jpg、html 静态文件时,Swoole 底层会直接发送内容,不会触发 onRequest 回调函数。

下载地址:

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Swoole 1.9.17 发布,增加静态文件处理器
分享
评论(18)
精彩评论
4
@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish
1

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008
你傻吗,eechn操你菊花了?
1
基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.
最新评论
0
swoole越来越稳定了,大赞
0

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008

引用来自“mengm0”的评论

如果这都不算……
只是转载链接,不要多想。兼听则明
0

引用来自“eechen”的评论

基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008

引用来自“orpherus”的评论

你是暗恋eechen吗
只是转载链接。
0

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008

引用来自“EBCMS”的评论

你傻吗,eechn操你菊花了?
口真臭,你应该刷牙了。我只是转载链接而已。
0

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish
你这80mb怎么算的,明显不对
1

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008
你傻吗,eechn操你菊花了?
0

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish
回复@eechen : 超过了排队多了会不会导致mysql宕机
0

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008
如果这都不算……
0

引用来自“eechen”的评论

@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish
异步回调的编程风格跟支持await之前的nodejs一样,业务逻辑稍微复杂点,写起来就不大好维护了,还是go或者elixir之类的协程同步风格简单点。swoole什么时候也以协程为主呢?
4
@漆黑的烈焰使 MySQL的最大连接数max_connections默认151.
MySQL也是用1个线程来处理1个连接的,也就是同一时间MySQL最多能处理151个SQL连接,超过了就只能排队.
阿里的AliSQL就对排队做了优化:
https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory
测试中可见MySQL在16和32线程(跟CPU核心数或超线程数一样)时表现是最好的.
而AliSQL因为引入了排队的机制,所以在线程数更多时,仍能保持稳定的吞吐量.

我在Ubuntu本子上简单测试了PHP用new mysqli建立短连接的性能,RPS能达到4200多.

@orpherus 每秒1次的短轮询会产生太多无用的HTTP请求,太消耗和浪费带宽了.
而长轮询可以让每次HTTP请求在服务器端hold住60秒(或者更大一些),
PHP在这60秒内如果收到Redis消息,就可以立刻结束请求返回数据给浏览器,
浏览器拿到数据后再一次发起一个AJAX长轮询请求,周而复始.

如果你想一个用户只能保持一个AJAX长轮询同样可行,
就是PHP在subscribe订阅当前用户的Redis频道前,
先用pubsub判断自己的频道是否存在,存在则publish消息告诉另一个连接下线,
然后自己在subscribe订阅用户频道,比如频道名:
mywebim:user:10086:channel
Redis消息通信涉及的命令主要有:
pubsub/subscribe/unsubscribe/publish

引用来自“eechen”的评论

基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.
请问同一时间连接数据库的连接过多会导致数据库马上挂掉吗,还是会排队按顺序执行,数据库这么脆弱的吗?mysql怎么知道最大并发连接数和设置
0
好是挺好的,就是文档还有很大进步空间
0

引用来自“eechen”的评论

基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.
如果用短轮询,每个核能做到1000请求每秒,12核的机器,是不是可以支撑每秒轮询一次的10K并发客户端了?
0

引用来自“eechen”的评论

基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.

引用来自“开源中国首席屌炸天”的评论

OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008
你是暗恋eechen吗
0

引用来自“eechen”的评论

基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.
OSC成立以来点赞次数最多的一条动弹, 让你了解一个真实的 @eechen ,传送门: http://my.oschina.net/bery/tweet/9658008
1
基于AJAX长轮询开发小规模的即时通讯程序,
比如公司内部使用的只有几百个客户端并发的WebIM,
因为AJAX长轮询本质还是HTTP,还是请求响应,
所以用PHP最原始的Apache MOD_PHP就能应付.
Apache event MPM 开 4进程*64线程=256 个线程,内存占用大概是 4进程*80MB=320MB.
也就是说,这是Apache+PHP可以hold住256个AJAX长轮询请求,一个线程hold住一个连接,非常传统的做法.
测试时,ab并发255,表示ab占用了255个线程,Apache还剩下一个线程,
这时通过浏览器或curl访问Apache,速度依然很快,因为还有1个空闲的线程可以处理请求,不需要排队.

PHP里的逻辑,等待消息不需要while轮询,直接用phpredis订阅subscribe消息就会进入阻塞状态,
超过default_socket_timeout(默认60秒)请求就会被PHP自动中断,中断时Redis连接被断开,订阅操作会自动被取消,
同时也可以在register_shutdown_function放一些请求结束时的逻辑.

上面这种方法适用于小规模(百级别的并发)通讯服务,好处是不用改变原来PHP的编程习惯,比较简单.
当然了,要做C10K(万级别的并发)的即时通讯服务,建议用异步的Swoole.
0
支持!
0
顶部