【问题标题】:Very low request per second values as a resut of Apache ab test on nginx server由于 nginx 服务器上的 Apache ab 测试,每秒请求值非常低
【发布时间】:2012-10-02 22:04:52
【问题描述】:

我正在使用以下设置测试我的新网站 * 2 个 m1.large ec2 实例作为弹性负载均衡器后面的 Web 服务器 * 两个网络服务器都安装了 memcache/apc/nginx/php-fpm * 1 m1.large ec2 实例用于 mongo db 当我从远程服务器运行它时 ab -n 100 http://beta.domain.com/ 我得到以下结果

Server Software:        nginx/1.1.19
Server Hostname:        beta.domain.com
Server Port:            80

Document Path:          /
Document Length:        50817 bytes

Concurrency Level:      1
Time taken for tests:   127.032 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      5117100 bytes
HTML transferred:       5081700 bytes
Requests per second:    0.79 [#/sec] (mean)
Time per request:       1270.322 [ms] (mean)
Time per request:       1270.322 [ms] (mean, across all concurrent requests)
Transfer rate:          39.34 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       21   42 100.4     26    1018
Processing:  1119 1228  69.4   1218    1488
Waiting:      941 1016  41.8   1015    1159
Total:       1144 1270 121.6   1246    2199

Percentage of the requests served within a certain time (ms)
  50%   1246
  66%   1271
  75%   1281
  80%   1295
  90%   1364
  95%   1483
  98%   1547
  99%   2199
 100%   2199 (longest request)

APC 命中率约为 98%。此外,我在进行此测试时正在检查 memcached 日志文件,我可以看到 ab 正在访问两台服务器并访问 memcached 上的值(全部命中,没有未命中)。但 RPS 值仍然是 0.79。这不是很低吗?我是否错过了这里的重点?

编辑

此外,所有静态内容(css、js、图像)都从 Amazon S3 以 gz 格式提供,并且有效期为 1 年。

*编辑 2 *

我使用-c 50 参数运行了相同的测试,结果如下

Concurrency Level:      50
Time taken for tests:   49.332 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      5118200 bytes
HTML transferred:       5082800 bytes
Requests per second:    2.03 [#/sec] (mean)
Time per request:       24666.145 [ms] (mean)
Time per request:       493.323 [ms] (mean, across all concurrent requests)
Transfer rate:          101.32 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       20   33  10.0     30      58
Processing:  7656 20521 6139.1  21495   29328
Waiting:     7538 20415 6131.9  21407   29243
Total:       7687 20554 6140.3  21540   29380

Percentage of the requests served within a certain time (ms)
  50%  21540
  66%  23255
  75%  25744
  80%  26204
  90%  27414
  95%  28098
  98%  29259
  99%  29380
 100%  29380 (longest request)

** 负载生成**

我猜是 ab 做的,不是吗?抱歉,我对基准测试很陌生 :) 我还添加了 -c 50 并再次运行测试。查看上面的结果。

** 测试页面**

此页面列出了 20 个带有图像、描述等的产品。进行一些后端计算,但结果都缓存在 memcache 中,因此它从未真正命中数据库 (mongo)。我可以从 memcache 日志文件中看到这一点。

** 还有什么 **

这是 ab 测试期间在其中一台服务器上vmstat 的结果

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 7161224  21028 199896    0    0    26    16   29   30  1  0 99  0

iostat

Linux 3.2.0-29-virtual  10/02/2012  _x86_64_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.67    0.00    0.31    0.15    0.34   98.54

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1            4.25        48.00        32.40     178001     120160
xvdb              0.17         0.54         0.00       1993          4

【问题讨论】:

    标签: nginx amazon-ec2 memcached apc apachebench


    【解决方案1】:

    这是否低取决于许多因素。

    负载生成

    您是如何产生负载的?如果您一次发送一个请求,则该值可能并非不合理。您发送了多少并发请求?

    测试页面有什么作用?

    该页面的处理量有多大?在系统没有任何负载的情况下完全加载页面需要多长时间?

    还有什么要检查的

    假设上述两个都没有出现问题,请查看服务器上的哪些资源正在征税。

    使用

    vmstat

    iostat

    找出性能下降的地方。 CPU是固定的吗?磁盘队列有多长?您是否正在使用所有可用内存?

    AWS 特定

    如果您有任何重要的 IO,您会发现 EBS 存储并不是很快。该问题的解决方案一直是将多个 EBS 卷条带化到软件 RAID 中

    http://www.mysqlperformanceblog.com/2009/08/06/ec2ebs-single-and-raid-volumes-io-bencmark/

    最近 AWS 发布了一项名为 Provisioned IO 的新服务,该服务将保证来自 EBS 卷的一定数量的磁盘 IO。它更昂贵,但不需要任何特殊配置即可使用(创建 EBS 卷时必须选择适当的选项)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-06-23
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多