Home  >  Article  >  Backend Development  >  nosql - redis的php客户端为什么连接数这么大

nosql - redis的php客户端为什么连接数这么大

WBOY
WBOYOriginal
2016-06-06 20:52:311075browse

我在网站中使用了redis作为缓存系统,并且用了它的pecl客户端(就是这个 https://github.com/nicolasff/phpredis)。使用没什么问题,但是最近再看链接数的时候发现了个问题,就是后台链接数特别高

nosql - redis的php客户端为什么连接数这么大

上图可以看到netstat -na | grep 6379后的端口占用情况,其实还有几个屏幕,我就不贴了。我想问的是,这是客户端的bug还是它本身就是这样?如果它本身就是这样,那这样占用下去会不会出什么问题,还是它自己有个上限的?因为我没有看到它的配置或者初始化参数里有连接池之类的设置,所以可以肯定这应该不是连接池的hold状态。

我看到它的连接方法有connectpconnect,我目前用的是connect,因为参照对mysql_pconnect的理解,现在请求数不是很大,也就没有必要用connect,而且它也应该在脚本结束后释放连接。现在的情况是,这些连接似乎只会在redis的server端在超时时间30秒后被自动断掉。

我担心如果以后请求数大了,30秒内就会被撑暴了。

回复内容:

我在网站中使用了redis作为缓存系统,并且用了它的pecl客户端(就是这个 https://github.com/nicolasff/phpredis)。使用没什么问题,但是最近再看链接数的时候发现了个问题,就是后台链接数特别高

nosql - redis的php客户端为什么连接数这么大

上图可以看到netstat -na | grep 6379后的端口占用情况,其实还有几个屏幕,我就不贴了。我想问的是,这是客户端的bug还是它本身就是这样?如果它本身就是这样,那这样占用下去会不会出什么问题,还是它自己有个上限的?因为我没有看到它的配置或者初始化参数里有连接池之类的设置,所以可以肯定这应该不是连接池的hold状态。

我看到它的连接方法有connectpconnect,我目前用的是connect,因为参照对mysql_pconnect的理解,现在请求数不是很大,也就没有必要用connect,而且它也应该在脚本结束后释放连接。现在的情况是,这些连接似乎只会在redis的server端在超时时间30秒后被自动断掉。

我担心如果以后请求数大了,30秒内就会被撑暴了。

我也使用的是这个插件,经过我的测试,这绝对是此redis客户端一个坑爹的设计!因为它居然要自己去关闭连接,关闭连接对php的开发者是一个几乎要遗忘的操作。

因为一般扩展的开发者,都会在脚本结束时自己关闭已经使用的连接,但是这个插件居然没有,而是需要你自己去关闭。当然关闭连接对只对connect函数有效,pconnect是不需要关闭连接的。其具体使用方法就是在脚本结束前调用redis对象的close方法,来关闭连接。或者更省事点,用类似下面的代码

register_shutdown_function(function () {
    global $redis;
    $redis->close();
});

经过测试,自己关闭连接后,用netstat -na看6379端口的连接就很少了。

你都是用的短连接,所有有那么多的timewait的连接,这个很正常,改成pconnect试试,会好点。短连接的情况下这个是正常的。

怎么回答你呢,请先回答我几个问题
第一,Redis的默认时间设置在redis.conf中timeout是300秒,请问是否修改过这个参数,修改为多少了?
第二,你用的这个redis扩展,这种用法$redis->connect('127.0.0.1', 6379);意味着超时时间未设置,会一直不超时。关于这点,请详细查看该扩展的文章。

根据你提供的不多的信息估计,最可能的是第二条中你未设置连接时间,用了默认不超时的方式。但是你说的是在30秒后断开,又不是符合redis.conf的默认配置。除非你修改了默认配置就说的通了。

得用pconnect啊,这个是带连接池的

我也遇到了如上问题,我用的是 pconnect连接,只是测试阶段,就有大批的连接.有时候甚至造成了php的进程挂掉.到底是用pconnect还是短连接+关闭连接呢?有没有一个合理的建议?再次膜拜!!!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn