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
