openresty 切片吞吐量的问题

hsl4235 · 2015-07-28T10:00:57+00:00

谢谢章哥，nginx-systemtap-toolkit 工具非常好用！在 2015年7月27...

openresty 切片吞吐量的问题

hsl4235

Hi：

又要来麻烦章哥了，因为公司需要，我在openresty里添加了一个模块，功能是proxy_cache的时候，我将缓存文件切成一个个固定大小的片段来保存。

我设计的原理是利用subrequest，将原本请求一个完整的文件，改造成206的请求，缓存的key是 uri+range(0-10M), 透传到后端也是发送一个个的206来请求并缓存，本地hit的时候也是拆成206的请求去查询key，总体来将，与原始版本相对比，吞吐量有些降低，我查看了火烟图，看不出是哪个接口消耗了性能。麻烦章哥能指点一下吗？

我将core里面的子请求200个数限制放开了。总感觉发送子请求这类方式来切片，原理上会有些问题。

附件是利用sample-bt 抓的五分钟火焰图

Attachment: trace.svg
Description: image/svg

agentzh

Hello!

2015-07-28 10:00 GMT+08:00 韩世林:
>     我设计的原理是利用subrequest，将原本请求一个完整的文件，改造成206的请求，缓存的key是 uri+range(0-10M),
> 透传到后端也是发送一个个的206来请求并缓存，

希望你切的片不至于过碎。

> 本地hit的时候也是拆成206的请求去查询key，总体来将，与原始版本相对比，吞吐量有些降低，我查看了火烟图，
> 看不出是哪个接口消耗了性能。麻烦章哥能指点一下吗？

你给的这个火焰图是 on-CPU
类型的火焰图，则大部分时间都花在系统调用上，也没什么特别之处。作为比较，建议同时提供切分前后的同种类型的火焰图，这样我们才方便比较。

我想问一句，当你的 nginx worker 进程满载时，CPU 的使用率情况是怎样的？有没有耗尽（几乎）所有的 CPU 资源？如果你的
nginx worker 进程的 CPU 使用率总是压不上去，则建议再作一张满载时的 off-CPU 类型的火焰图，即使用下面这个工具：

    https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu

Regards,
-agentzh

membphis

你们这个功能需求，我们也有类似的应用场景。

问下可以共享不？

😄

2015-07-28 10:00 GMT+08:00 韩世林 <hsl...@gmail.com>:

Hi：
又要来麻烦章哥了，因为公司需要，我在openresty里添加了一个模块，功能是proxy_cache的时候，我将缓存文件切成一个个固定大小的片段来保存。
我设计的原理是利用subrequest，将原本请求一个完整的文件，改造成206的请求，缓存的key是 uri+range(0-10M), 透传到后端也是发送一个个的206来请求并缓存，本地hit的时候也是拆成206的请求去查询key，总体来将，与原始版本相对比，吞吐量有些降低，我查看了火烟图，看不出是哪个接口消耗了性能。麻烦章哥能指点一下吗？
我将core里面的子请求200个数限制放开了。总感觉发送子请求这类方式来切片，原理上会有些问题。
附件是利用sample-bt 抓的五分钟火焰图

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

hsl4235

1: 我现在配置上都是按照10M的大小固定来进行切片。应该不至于很碎。或者我提高切片的大小再测试下看看吞吐量有明显变化，但是切片过大，意义也就不存在了。

2: 我做了两个对比图，一个oncpu，另一个是offcpu，之前我测试过单台的压力，跑到五六个G，负载跟cpu 压力都是很好，变化不大。

在 2015年7月28日星期二 UTC+8下午1:54:42，agentzh写道：

Hello!

2015-07-28 10:00 GMT+08:00 韩世林:
> 我设计的原理是利用subrequest，将原本请求一个完整的文件，改造成206的请求，缓存的key是 uri+range(0-10M),
> 透传到后端也是发送一个个的206来请求并缓存，

希望你切的片不至于过碎。

> 本地hit的时候也是拆成206的请求去查询key，总体来将，与原始版本相对比，吞吐量有些降低，我查看了火烟图，
> 看不出是哪个接口消耗了性能。麻烦章哥能指点一下吗？

你给的这个火焰图是 on-CPU
类型的火焰图，则大部分时间都花在系统调用上，也没什么特别之处。作为比较，建议同时提供切分前后的同种类型的火焰图，这样我们才方便比较。

我想问一句，当你的 nginx worker 进程满载时，CPU 的使用率情况是怎样的？有没有耗尽（几乎）所有的 CPU 资源？如果你的
nginx worker 进程的 CPU 使用率总是压不上去，则建议再作一张满载时的 off-CPU 类型的火焰图，即使用下面这个工具：

https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu

Regards,
-agentzh

Attachment: bt-off-trace.svg
Description: image/svg

Attachment: bt-on-trace.svg
Description: image/svg

Attachment: subrange-bt-off-trace.svg
Description: image/svg

Attachment: subrange-bt-on-trace.svg
Description: image/svg

hsl4235

嗯，我过几天放到github上去

在 2015年7月28日星期二 UTC+8下午2:37:40，YuanSheng Wang写道：

你们这个功能需求，我们也有类似的应用场景。

问下可以共享不？

😄

2015-07-28 10:00 GMT+08:00 韩世林 <hsl...@gmail.com>:
Hi：
又要来麻烦章哥了，因为公司需要，我在openresty里添加了一个模块，功能是proxy_cache的时候，我将缓存文件切成一个个固定大小的片段来保存。
我设计的原理是利用subrequest，将原本请求一个完整的文件，改造成206的请求，缓存的key是 uri+range(0-10M), 透传到后端也是发送一个个的206来请求并缓存，本地hit的时候也是拆成206的请求去查询key，总体来将，与原始版本相对比，吞吐量有些降低，我查看了火烟图，看不出是哪个接口消耗了性能。麻烦章哥能指点一下吗？
我将core里面的子请求200个数限制放开了。总感觉发送子请求这类方式来切片，原理上会有些问题。
附件是利用sample-bt 抓的五分钟火焰图

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

agentzh

Hello!

从火焰图上看，你实验前后的主要区别很可能是系统调用的次数增加了。建议在减少系统调用次数方面下工夫。

Regards,
-agentzh

2015-07-29 10:49 GMT+08:00 韩世林 <hsl...@gmail.com>:
> 1:  我现在配置上 都是按照10M的大小固定来进行切片。应该不至于很碎。或者我提高切片的大小再测试下看看吞吐量有明显变化，
> 但是切片过大，意义也就不存在了。
> 2:  我做了两个对比图， 一个oncpu， 另一个是offcpu，之前我测试过单台的压力， 跑到五六个G， 负载跟cpu 压力都是很好，变化不大。
>
> 在 2015年7月28日星期二 UTC+8下午1:54:42，agentzh写道：
>>
>> Hello!
>>
>> 2015-07-28 10:00 GMT+08:00 韩世林:
>> >     我设计的原理是利用subrequest，将原本请求一个完整的文件，改造成206的请求，缓存的key是 uri+range(0-10M),
>> > 透传到后端也是发送一个个的206来请求并缓存，
>>
>> 希望你切的片不至于过碎。
>>
>> > 本地hit的时候也是拆成206的请求去查询key，总体来将，与原始版本相对比，吞吐量有些降低，我查看了火烟图，
>> > 看不出是哪个接口消耗了性能。麻烦章哥能指点一下吗？
>>
>> 你给的这个火焰图是 on-CPU
>> 类型的火焰图，则大部分时间都花在系统调用上，也没什么特别之处。作为比较，建议同时提供切分前后的同种类型的火焰图，这样我们才方便比较。
>>
>> 我想问一句，当你的 nginx worker 进程满载时，CPU 的使用率情况是怎样的？有没有耗尽（几乎）所有的 CPU 资源？如果你的
>> nginx worker 进程的 CPU 使用率总是压不上去，则建议再作一张满载时的 off-CPU 类型的火焰图，即使用下面这个工具：
>>
>>     https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu
>>
>> Regards,
>> -agentzh