1

我正在以下设置上测试我的新站点 * 2 个 m1.large ec2 实例作为弹性负载均衡器后面的 Web 服务器 * 两个 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 日志文件中看到这一点。

** 还有什么 **

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

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
4

1 回答 1

0

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

负载生成

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

测试页面有什么作用?

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

还有什么要检查的

假设上述两种情况都没有出现问题,请查看服务器上对哪些资源征税。

采用

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 卷时必须选择适当的选项)。

于 2012-10-02T22:12:00.733 回答