你好！
在使用lua-resty-redis时，调用set_keepalive的时机是在什么时候，是在建立建立连接后就可以直接调用set_keepalive吗？
类似这样的代码序列：
local ok, err = red:connect(ip, port)
ok, err = red:set_keepalive(10000, 100)
还是必须在建立连接后，先进行实际的redis指令操作后，再跳用:set_keepalive方法呢？
在 2013年9月17日星期二 UTC+8下午1:10:21，Jakin写道：
春哥推荐了 使用 lua-resty-redis 吧
我这边 使用 lua-resty-redis 轻松5W 长连接没事... 而且服务器只不过是阿里云而已
------------------ 原始邮件 ------------------
发送时间: 2013年9月17日(星期二) 中午12:07
主题: Re: [openresty] nginx与后端redis连接数很高
谢谢agentzh的回复，今天在线上试验了下，
是keepalive设置的值太大了，看了论坛里面的其他帖子，keepalive是针对每个worker缓存的连接数，我的服务器一个nginx是8个worker，这样平均每台可缓存的连接数8k，一共4台服务器，在服务忙碌时会导致4台服务器连接到redis的连接高于2w，由于后端redis设置了maxclients 是2w，这样就把redis连接全部占满了，出现upstream timeout的错误。 不知道我这样的理解对不对？
在 2013年9月17日星期二UTC+8上午1时54分32秒，
agentzh写道：
Hello!
2013/9/16 谭俊东:
>
> 一个请求会查5次redis库，平均单台nginx的qps在700左右，线上遇到redis连接数一直都爆满，
“Redis 连接数爆满”是多满？你是如何检查的，检查的具体结果是？
> 设置了2w的请求，也是爆满，
什么叫做“设置了2w的请求”？不好意思，我看不懂这种说法。
> nginx出现如下错误
> 413130677 upstream timed out (110: Connection timed out) while reading
> response header from upstream, client:
>
单从这个错误看，是你的 redis 服务器过忙而来不及处理请求；换句话说，你的 redis
服务器本身是瓶颈。你需要使用相关的系统工具加以确认，比如使用 ngx-recv-queue 工具：
https://github.com/agentzh/nginx-systemtap-toolkit#ngx-recv-queue
> 是否采用如上这种配置，nginx与后端redis的链接不是使用长连接方式？
>
设置了 keepalive 配置指令便会使用 TCP 连接池。你总是可以通过 netstat
这样的系统工具来确认连接池是否生效（比如检查指向 redis 的 TIME_WAIT 和 ESTABLISHED 状态的连接）。
另外，TCP 连接池的容量不宜设置过大。你应当根据你线上实际的并发度和你配置的 nginx worker 进程的数目进行设置。
另外，推荐换用 lua-resty-redis 库：
https://github.com/agentzh/lua-resty-redis
这样你的配置可以大大减化，同时可以避免 nginx 子请求的开销，同时你也可以设置连接在连接池中的最大空闲时间，以避免过剩的 redis 长连接永不关闭。
Regards,
-agentzh
--
