多谢agentzh的详细的解答！
在 2014年3月26日 上午3:46，Yichun Zhang (agentzh) <age...@gmail.com>写道：
>
> Hello!
>
> 2014-03-24 8:01 GMT-07:00 李阳光:
> > 我基于lua开发了一个流量路由模块，其中使用shared.DICT作为路由规则的存储介质，主要是为了实现规则的动态更新，
> > 内部主要功能是：三次json的反序列化，正则匹配，三次读取某个DICT.
>
> 你能提供你的核心部分的代码片段吗？最好能提供一个最小化的完整示例，以及具体的测试步骤，以便我可以在我本地复现你看到的性能问题。这样我可以直接帮你优化。
流量路由的核心的执行流程：
1. 从shared.dict中取出按照规则的优先级的排序好的rule_ids(需要json decode)
2. 再根据rule_ids取出每个id的对应rule的详细规则（需要json decode）
3. 针对每个HTTP request依次匹配每条规则，包括url_match, 或者IP规则等
4. 如果匹配某条规则后，直接退出，使用该规则的target_cluster及document_root,
向后端的upstream发送请求
每条规则的数据结构类似：
{"id": 1, "url_pattern": "^/(?:index.php)?\\?action=image",
"condition_type": "IP", "condition_key": "", "match_type":
"PERCENTAGE", "condition_value_format": "TEXT", "condition_value":
"60", "target_cluster": "image_cluster", "target_type": "FASTCGI",
"priority":1, "document_root": "/var/www/htdocs/"}
#这条规则相当于将60%的流量action=image的流量分配到image_cluster上
ps: json库是使用cjson.so的库
>
> 一些比较一般性的建议是：
>
> 1. 使用最新版的 openresty:
>
> http://openresty.org/download/ngx_openresty-1.5.11.1rc3.tar.gz
>
> 2. 尝试在 nginx.conf 中的 http {} 块中添加下面这一段配置以启用 lua-resty-core:
>
> init_by_lua '
> require "resty.core"
> ';
我还未使用openresty的库，只是用了nginx lua module，不知这个做了什么优化呢？
>
> 3. 在进行压测时时刻检查 nginx 的错误日志，以避免 nginx 把大部分时间花在刷错误日志文件上面。
在errror.log里没有错误日志
>
> 4. 设置合理数量的 nginx worker（一般与逻辑 CPU 核一一对应），并正确地配置 worker_cpu_affinity 指令：
>
> http://nginx.org/en/docs/ngx_core_module.html#worker_cpu_affinity
这个已经设置
>
> 5. 尽量使用更为高效的序列化格式和实现，例如：
>
> https://github.com/guanlan/lua-cmsgpack
>
> https://github.com/cloudflare/lua-capnproto
好的，这个可以试下，不知比cjson有多大的性能特省
>
> > 目前对其做了个整体的性能测试，测试工具Jmeter.
> > side by side测试 : 使用lua实现的流量路由模块， 使用nginx配置来实现流量路由模块
> > 有几点疑惑：
> > a. 当测试并发在1000以下时，CPU的idle比nginx原有的流量路由功能降低了40%左右，
> > 最大qps和latency相差在10%左右
> > b. 当并发数在1000以上递增时(1000, 2000, 3000)，此时cpu idle反而开始增加，qps随之下降，这是为何呢？
>
> 我需要更多的信息以便向你提供比较具体的优化建议。特别地，我需要你的 nginx 在满载时的 on-CPU 和 off-CPU 火焰图。见
>
> https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt
>
> 以及
>
> https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-off-cpu
这个工具不太熟悉，之后给出这个火焰图
>
> > 而且每个request的latency与原有的差别越来越大，当并发在5000时，latency差距在90ms左右（29ms , 114ms）
> > 此时感觉DICT的性能下降的非常厉害
> >
>
> 这个现象一般说明你的客户端发出的请求速率已经超出 server
> 能处理的极限了。建议在测试越来越大的并发度的时候，使用支持固定总体请求速率的压测工具。你用的 Jmeter 工具很可能像 ab
> 一样总是尝试在每一个并发连接上尽可能多地发送请求，于是很容易让服务器端超出吞吐量极限。
这里还有一点不太理解，当并发很大时，nginx的qps随之降低了很多了，但是cpu idle还是比较高的，并不是cpu自愿紧张，不知为何
随着并发的增加，qps会下降呢？
另外，一般对nginx的性能测试的话，多少并发比较合适，是让nginx达到最大的qps比较合适吗
>
> Regards,
> -agentzh
>
> --
>
