ab测试网站吞吐率介绍

吞吐率介绍  

何为吞吐率,解释下,就是在单位时间内服务器处理的请求数,这也许是我们衡量一个WEB站点很重要的一个指标,当10个用户同时发起100请求和1 个用户 同时向服务器发起1000个请求,我们的效果是不是一样呢,这里有个概念要说明一下,连续请求的意思是一个用户的请求通过服务器并返回进行下一次请求这个 过程成为连续的请求,当我们10个用户发起100个请求的时候,每个用户的请求都会阻塞在缓冲区内,等待下一个请求的返回,所以显然两种方式的操作对站点 的影响是完全不同的,下面我们利用APACHE自带的性能测试工具AB来测试我们的吞吐率,在linux环境下输入(自己打到自己APACHE的安装目 录),
xiahan@xiahan-desktop:/usr/ali/apache2/bin$  ab -n1000 -c10 http://cn.my.alibaba.com:12608/index.htm 
得到如下结果
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking cn.my.alibaba.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:

       Apache/2.0.59
Server Hostname:        cn.my.alibaba.com
Server Port:            12608

Document Path:          /index.htm
Document Length:        0 bytes

Concurrency Level:      10
Time taken for tests:   8.636 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      1023000 bytes
HTML transferred:       0 bytes
Requests per second:    115.79 [#/sec] (mean) 
Time per request:       86.364 [ms] (mean)
Time per request:       8.636 [ms] (mean, across all concurrent requests)
Transfer rate:          115.68 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.1      0      36
Processing:     8   85 282.2     27    3242
Waiting:        8   85 281.6     27    3242
Total:          8   86 282.5     28    3242

Percentage of the requests served within a certain time (ms)
  50%     28
  66%     49
  75%     64
  80%     77
  90%    132
  95%    289
  98%    513
  99%   1370
100%   3242 (longest request)

-n1000表示1000个请求,-c10表示10个用户,下面来解释下几个重要的结果指标
Request per request:这就是我们重点关注的吞吐率,他等于 Complete requests/Time taken for tests
Time per request:用户平均等待的时间,他等于Time taken for/(Complete requests/Concurrency Level)
Time per request06110930_zP1L.gifmean, across all concurrent requests)服务器平均处理请求的时间,他等于
Time taken for /Complete requests
这就是一些重要的指标
当我们换成1个用户10个请求的时候,他的吞吐量会增加(由于篇幅原因就不打印出数据了),但是当我们为10个用户,10000个请求的时候吞吐率就会下 降,这说明了一个问题,当我们到达一个临界点的时候,是我们吞吐量最高的时候,当请求和用户数再增加的时候可能吞吐量就会下降,打个比方我们跑步的时候跑 20米一点不觉得累,跑30米也不会觉得累,当你跑到100米的时候感觉正好不累也不轻松,但是当你超过100米的时候,你就会感觉喘气,那100米就是 一个临界点,服务器处理的能力也类似于这个,但是光是我们掌握到最佳并发策略的web服务器的使用,我们就能应对各种各样的并发用户请求,答案显然不是,  



刚刚的测试,首页吞吐率,见下图的 Request per second
06110932_qg0W.jpg

这个值虽然没有代表意义,只是热点页面的优化,但性能仍然是惊人的

2509*60*60*12=108388800 (一天12小时,应付单台机器一亿多pv)
2509*60*60*8=72259200 (少一点,算8小时,应付七千多万pv)
2509*60*60*2=18064800 (按高峰期来算,一般情况算四分之一,应付1800万pv)

转载于:https://my.oschina.net/catandpaperball/blog/501612

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值