On Sunday, April 14, 2013 11:39:57 AM UTC+8, 黄力 wrote:
On Saturday, April 13, 2013 11:51:41 PM UTC+8, agentzh wrote:Hello!
2013/4/13 黄力li.huang:
>> 貌似你的连接池未能生效,很可能是因为有连接超时等错误出现。连接上的错误会导致连接被强行关闭。
>
> 现在发现对于外网memcached存在不少connect timeout和set
> timeout,
请提供原始的错误日志,而不是自然语言描述,因为后者丢失了很多重要信息 :)
好的,今天在家无法登陆server,明天去公司拷贝上来。春哥,这里悄悄的问一句 :CF哪些模块用了lua?
另外,你从运行 nginx 的机器测试过你的外网 memcached
的性能极限么?特别是整体的吞吐量上限。当超过这个服务的负载能力时,自然会看到很多超时。同时由于外网的网络不确定因素多,出现超时的机会本来就大,仔细把你的外网带宽耗尽。
说的是,我到没有测试过从nginx测试机打外网memcached的性能,明天试试。
> 我现在已经memc:set_timeout(600000)
> ,十分钟,但是好像不到一分钟就timeout了,有没有什么好的解决办法?
1. 你说超时设置提前触发,你的根据是什么?
因为当时我只起了10个并发,从压力开始没多久,error.log里就出了failed to connect......time out和 failed to set .......timedout。之前我以为起100个并发压力太大把带宽耗尽了才会出现这些timeout,没想到起10个并发的压力也一样。
2. 使用过大的超时是应绝对避免的,因这这个时间会加进你的请求服务时间中去。
是啊,我也怕这样,那就不能用了。
3. 我觉得像这种涉及外网的缓存同步操作还是放在 nginx 外部来做更合适一些。比如换用 redis 作为缓存存储,并使用它的
master-slave replication 机制自己进行数据同步。
这个我们也评估过,但是,我们每个节点的网站缓存数据不一样,再加上往一个redis node写入,让它自己同步到其它node这个有些慢,不得已才想到在srcache里发多条store指令来满足实时同步缓存的目的。
> 我现在已经把不同机器的set请求放到corountine里了,见附件,不过这样改的话,
使用 Lua 标准的 coroutine API 并不能让串行请求并行化,只是徒增额外的开销罢了。或许你这里需要的是 ngx.thread.* API?
http://wiki.nginx.org/HttpLuaModule#ngx.thread.spawn
提高后端访问的并发度可以减少单个请求的响应延时,但不会增加系统整体的吞吐量(事实上,整体吞吐量反而会略有下降)。
这么好啊!我又激动了,呵呵。
附件的程序,帮忙看看,哪里写的不妥。还有下面写法在wait成功时res是nil
local threads = {}
for _, ip in ipairs(iplist) do
local tf, err = ngx.thread.spawn(store, memcached, key, data, ip)
if not tf then
ngx.say("failed to spawn thread f: ", err)
return
end
table.insert(threads, tf)
end
for i = 1, #threads do
local ok, res = ngx.thread.wait(threads[i])
if not ok then
say(i, ": failed to run: ", res)
else
say(i, ": status: ", res.status)
say(i, ": body: ", res.body)
end
end
> 更容易把网络带宽耗尽吧?那时timeout就更多了。
你为什么不直接对你的网络带宽本身进行测试和计量?猜测是得不出结论的 :)
您说的是,明天去仔细测测。
Best regards,
-agentzh
Attachment:
set.lua
Description: Binary data