Hello! 2012/12/24 杨嵩: > 1.第一次会很慢,再刷新就快了,但是刷新几次又慢了! > 2.如何才能做到,一个比较稳定的连接时长 > > 相比较来说,我觉得ngx_lua会相对稳定一些,不会出现php + fast_cgi连接多挂掉的问题, > 但是我希望我的API有一个比较稳定的请求时间。比如3或5秒之内返回。 > > 当前项目数据基本都来自solr(内网) > 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。 从最简单的可能工作的部件或者组合开始测试起。 Best regards, -agentzh
Hello! 2012/12/24 agentzh: > 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。 > > 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。 > > 从最简单的可能工作的部件或者组合开始测试起。 > 另外,关于是否阻塞的判断,也有一个很简单的做法,即只启用一个 nginx worker 进程,然后测试服务器的极限并发能力是否严格为 1. 因为一旦阻塞,便只有严格的 1 并发能力。 通过很简单的设计试验可以测量出 http 服务器的并发能力。考虑下面这个例子: worker_processes 1; server { listen 8080; location = /a { echo_sleep 1; echo $uri; } location = /b { echo_blocking_sleep 1; echo $uri; } } 这里 location = /a 中使用的 echo_sleep 指令是以非阻塞方式休眠 1 秒,而 location = /b 中使用的 echo_blocking_sleep 指令则是以阻塞方式休眠 1 秒。(关于这两条指令的更多细节,请参见它们的官方文档:http://wiki.nginx.org/HttpEchoModule#echo_sleep 与 http://wiki.nginx.org/HttpEchoModule#echo_blocking_sleep ) 现在我们使用 ab 来对它们分别以 4 并发进行压测: $ ab -c4 -n8 localhost:8080/a ... Requests per second: 3.99 [#/sec] (mean) ... ab -c4 -n8 localhost:8080/b ... Requests per second: 1.00 [#/sec] (mean) ... 对于 location = /a,4 并发下的吞吐量大约是 4 r/s,而我们已经请求的响应延时约是 1 秒,于是服务器端的并发度至少是 4(即 4 个请求可以同时在 1 秒内完成)。这验证了 location = /a 中的 echo_sleep 是非阻塞的。 而对于 location = /b 来说,4 并发下的吞吐量只有 1 r/s,即服务器端 1 秒内最多只能完成 1 个请求,即使 ab 在客户端尝试发起 4 个并发连接,这些并发请求在服务器端一侧也须排队以串行化方式服务。这验证了 echo_blocking_sleep 指令是阻塞的。 虽然这里我们是以 ngx_echo 模块的 echo_sleep 和 echo_blocking_sleep 指令作为测试对象。这种试验技术同样适用于其他任何东西,包括 lua-resty-http 库 :) Best regards, -agentzh
Hello!2012/12/24 agentzh:> 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。>> 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。>> 从最简单的可能工作的部件或者组合开始测试起。>另外,关于是否阻塞的判断,也有一个很简单的做法,即只启用一个 nginx worker 进程,然后测试服务器的极限并发能力是否严格为 1.因为一旦阻塞,便只有严格的 1 并发能力。通过很简单的设计试验可以测量出 http 服务器的并发能力。考虑下面这个例子: worker_processes 1; server { listen 8080; location = /a { echo_sleep 1; echo $uri; } location = /b { echo_blocking_sleep 1; echo $uri; } }这里 location = /a 中使用的 echo_sleep 指令是以非阻塞方式休眠 1 秒,而 location = /b 中使用的echo_blocking_sleep 指令则是以阻塞方式休眠 1秒。(关于这两条指令的更多细节,请参见它们的官方文档:http://wiki.nginx.org/HttpEchoModule#echo_sleep与 http://wiki.nginx.org/HttpEchoModule#echo_blocking_sleep )现在我们使用 ab 来对它们分别以 4 并发进行压测: $ ab -c4 -n8 localhost:8080/a ... Requests per second: 3.99 [#/sec] (mean) ... ab -c4 -n8 localhost:8080/b ... Requests per second: 1.00 [#/sec] (mean) ...对于 location = /a,4 并发下的吞吐量大约是 4 r/s,而我们已经请求的响应延时约是 1 秒,于是服务器端的并发度至少是4(即 4 个请求可以同时在 1 秒内完成)。这验证了 location = /a 中的 echo_sleep 是非阻塞的。而对于 location = /b 来说,4 并发下的吞吐量只有 1 r/s,即服务器端 1 秒内最多只能完成 1 个请求,即使 ab在客户端尝试发起 4 个并发连接,这些并发请求在服务器端一侧也须排队以串行化方式服务。这验证了 echo_blocking_sleep指令是阻塞的。虽然这里我们是以 ngx_echo 模块的 echo_sleep 和 echo_blocking_sleep指令作为测试对象。这种试验技术同样适用于其他任何东西,包括 lua-resty-http 库 :)Best regards,-agentzh
2012/12/24 agentzh:> 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。>> 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。>> 从最简单的可能工作的部件或者组合开始测试起。>
另外,关于是否阻塞的判断,也有一个很简单的做法,即只启用一个 nginx worker 进程,然后测试服务器的极限并发能力是否严格为 1.因为一旦阻塞,便只有严格的 1 并发能力。
通过很简单的设计试验可以测量出 http 服务器的并发能力。考虑下面这个例子:
worker_processes 1;
server { listen 8080;
location = /a { echo_sleep 1; echo $uri; }
location = /b { echo_blocking_sleep 1; echo $uri; } }
这里 location = /a 中使用的 echo_sleep 指令是以非阻塞方式休眠 1 秒,而 location = /b 中使用的echo_blocking_sleep 指令则是以阻塞方式休眠 1秒。(关于这两条指令的更多细节,请参见它们的官方文档:http://wiki.nginx.org/HttpEchoModule#echo_sleep与 http://wiki.nginx.org/HttpEchoModule#echo_blocking_sleep )
现在我们使用 ab 来对它们分别以 4 并发进行压测:
$ ab -c4 -n8 localhost:8080/a ... Requests per second: 3.99 [#/sec] (mean) ...
ab -c4 -n8 localhost:8080/b ... Requests per second: 1.00 [#/sec] (mean) ...
对于 location = /a,4 并发下的吞吐量大约是 4 r/s,而我们已经请求的响应延时约是 1 秒,于是服务器端的并发度至少是4(即 4 个请求可以同时在 1 秒内完成)。这验证了 location = /a 中的 echo_sleep 是非阻塞的。
而对于 location = /b 来说,4 并发下的吞吐量只有 1 r/s,即服务器端 1 秒内最多只能完成 1 个请求,即使 ab在客户端尝试发起 4 个并发连接,这些并发请求在服务器端一侧也须排队以串行化方式服务。这验证了 echo_blocking_sleep指令是阻塞的。
虽然这里我们是以 ngx_echo 模块的 echo_sleep 和 echo_blocking_sleep指令作为测试对象。这种试验技术同样适用于其他任何东西,包括 lua-resty-http 库 :)
Best regards,-agentzh
我按照你的方法,进行测试,确定他是非阻塞的, 不知道在lua中调用shell会不会也是非阻塞的,我需要搭个环境但是 echo_blocking_sleep 1; 这种情况在实际应用中应该很少会出现吧,并且我在用ab测试时,一个进程,可以获得Requests per second: 117.66 [#/sec] 不只是4个哦。(本机测试) 但是我在通过浏览器访问,第一次访问又很慢(非本机,非局域网),达到到1.12s,才打开,是不是有可能和域名的dns 以及 其他因素有关呢On Tuesday, December 25, 2012 3:54:07 AM UTC+8, agentzh wrote: Hello!2012/12/24 agentzh:> 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。>> 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。>> 从最简单的可能工作的部件或者组合开始测试起。 >另外,关于是否阻塞的判断,也有一个很简单的做法,即只启用一个 nginx worker 进程,然后测试服务器的极限并发能力是否严格为 1.因为一旦阻塞,便只有严格的 1 并发能力。通过很简单的设计试验可以测量出 http 服务器的并发能力。考虑下面这个例子: worker_processes 1; server { listen 8080; location = /a { echo_sleep 1; echo $uri; } location = /b { echo_blocking_sleep 1; echo $uri; } }这里 location = /a 中使用的 echo_sleep 指令是以非阻塞方式休眠 1 秒,而 location = /b 中使用的 echo_blocking_sleep 指令则是以阻塞方式休眠 1秒。(关于这两条指令的更多细节,请参见它们的官方文档:http://wiki.nginx.org/HttpEchoModule#echo_sleep与 http://wiki.nginx.org/HttpEchoModule#echo_blocking_sleep ) 现在我们使用 ab 来对它们分别以 4 并发进行压测: $ ab -c4 -n8 localhost:8080/a ... Requests per second: 3.99 [#/sec] (mean) ... ab -c4 -n8 localhost:8080/b ... Requests per second: 1.00 [#/sec] (mean) ...对于 location = /a,4 并发下的吞吐量大约是 4 r/s,而我们已经请求的响应延时约是 1 秒,于是服务器端的并发度至少是4(即 4 个请求可以同时在 1 秒内完成)。这验证了 location = /a 中的 echo_sleep 是非阻塞的。而对于 location = /b 来说,4 并发下的吞吐量只有 1 r/s,即服务器端 1 秒内最多只能完成 1 个请求,即使 ab 在客户端尝试发起 4 个并发连接,这些并发请求在服务器端一侧也须排队以串行化方式服务。这验证了 echo_blocking_sleep指令是阻塞的。虽然这里我们是以 ngx_echo 模块的 echo_sleep 和 echo_blocking_sleep指令作为测试对象。这种试验技术同样适用于其他任何东西,包括 lua-resty-http 库 :)Best regards, -agentzh
Hello!2012/12/24 agentzh:> 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。>> 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。>> 从最简单的可能工作的部件或者组合开始测试起。 >另外,关于是否阻塞的判断,也有一个很简单的做法,即只启用一个 nginx worker 进程,然后测试服务器的极限并发能力是否严格为 1.因为一旦阻塞,便只有严格的 1 并发能力。通过很简单的设计试验可以测量出 http 服务器的并发能力。考虑下面这个例子: worker_processes 1; server { listen 8080; location = /a { echo_sleep 1; echo $uri; } location = /b { echo_blocking_sleep 1; echo $uri; } }这里 location = /a 中使用的 echo_sleep 指令是以非阻塞方式休眠 1 秒,而 location = /b 中使用的 echo_blocking_sleep 指令则是以阻塞方式休眠 1秒。(关于这两条指令的更多细节,请参见它们的官方文档:http://wiki.nginx.org/HttpEchoModule#echo_sleep与 http://wiki.nginx.org/HttpEchoModule#echo_blocking_sleep ) 现在我们使用 ab 来对它们分别以 4 并发进行压测: $ ab -c4 -n8 localhost:8080/a ... Requests per second: 3.99 [#/sec] (mean) ... ab -c4 -n8 localhost:8080/b ... Requests per second: 1.00 [#/sec] (mean) ...对于 location = /a,4 并发下的吞吐量大约是 4 r/s,而我们已经请求的响应延时约是 1 秒,于是服务器端的并发度至少是4(即 4 个请求可以同时在 1 秒内完成)。这验证了 location = /a 中的 echo_sleep 是非阻塞的。而对于 location = /b 来说,4 并发下的吞吐量只有 1 r/s,即服务器端 1 秒内最多只能完成 1 个请求,即使 ab 在客户端尝试发起 4 个并发连接,这些并发请求在服务器端一侧也须排队以串行化方式服务。这验证了 echo_blocking_sleep指令是阻塞的。虽然这里我们是以 ngx_echo 模块的 echo_sleep 和 echo_blocking_sleep指令作为测试对象。这种试验技术同样适用于其他任何东西,包括 lua-resty-http 库 :)Best regards, -agentzh
2012/12/24 agentzh:> 请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题,都会出现延时不稳定。>> 一种常见的排查问题的方法类似诊断电路问题,即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口,然后单独测试你的 Lua 代码。>> 从最简单的可能工作的部件或者组合开始测试起。 >
这里 location = /a 中使用的 echo_sleep 指令是以非阻塞方式休眠 1 秒,而 location = /b 中使用的 echo_blocking_sleep 指令则是以阻塞方式休眠 1秒。(关于这两条指令的更多细节,请参见它们的官方文档:http://wiki.nginx.org/HttpEchoModule#echo_sleep与 http://wiki.nginx.org/HttpEchoModule#echo_blocking_sleep )
而对于 location = /b 来说,4 并发下的吞吐量只有 1 r/s,即服务器端 1 秒内最多只能完成 1 个请求,即使 ab 在客户端尝试发起 4 个并发连接,这些并发请求在服务器端一侧也须排队以串行化方式服务。这验证了 echo_blocking_sleep指令是阻塞的。
Best regards, -agentzh