Maison  >  Article  >  développement back-end  >  nosql - redis的php客户端为什么连接数这么大

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

WBOY
WBOYoriginal
2016-06-06 20:52:311077parcourir

我在网站中使用了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还是短连接+关闭连接呢?有没有一个合理的建议?再次膜拜!!!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn