请问如何判断是否被阻塞了呢，lua+resty_http+solr，是否会被阻塞与 php+solr有没有优势

netyum

1.第一次会很慢，再刷新就快了，但是刷新几次又慢了！

2.如何才能做到，一个比较稳定的连接时长

相比较来说，我觉得ngx_lua会相对稳定一些，不会出现php + fast_cgi连接多挂掉的问题，

但是我希望我的API有一个比较稳定的请求时间。比如3或5秒之内返回。

当前项目数据基本都来自solr（内网）

http://image.yiibook.com/solr

agentzh

Hello!

2012/12/24 杨嵩:
> 1.第一次会很慢，再刷新就快了，但是刷新几次又慢了！
> 2.如何才能做到，一个比较稳定的连接时长
>
> 相比较来说，我觉得ngx_lua会相对稳定一些，不会出现php + fast_cgi连接多挂掉的问题，
> 但是我希望我的API有一个比较稳定的请求时间。比如3或5秒之内返回。
>
> 当前项目数据基本都来自solr（内网）
>

请确认不是你的 solr 后端的稳定性问题。任何一个环节有问题，都会出现延时不稳定。

一种常见的排查问题的方法类似诊断电路问题，即分段测试连通性和可靠性。比如你可以用 nginx 提供一个伪造的 http 接口，然后单独测试你的 Lua 代码。

从最简单的可能工作的部件或者组合开始测试起。

Best regards,
-agentzh

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

netyum

我按照你的方法，进行测试，确定他是非阻塞的，　不知道在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

smallfish.xy

echo_blocking_sleep 只是为了模拟阻塞的情况而已，就像你在 lua 中调用 shell 一样，这个是阻塞的。

测试的时候尽量用 curl 来测试，更为直接方便。

smallfish http://chenxiaoyu.org

2012/12/25 杨嵩 <ne...@gmail.com>

我按照你的方法，进行测试，确定他是非阻塞的，　不知道在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