并发负载压力测试

ab命令原理 
Apache的ab命令模拟多线程并发请求,测试服务器负载压力,也可以测试nginx、lighthttp、IIS等其它Web服务器的压力。 
ab命令对发出负载的计算机要求很低,既不会占用很多CPU,也不会占用太多的内存,但却会给目标服务器造成巨大的负载,因此是某些DDOS攻击之必备良药,老少皆宜。自己使用也须谨慎。否则一次上太多的负载,造成目标服务器直接因内存耗光死机,而不得不硬重启,得不偿失。

在带宽不足的情况下,最好是本机进行测试,建议使用内网的另一台或者多台服务器通过内网进行测试,这样得出的数据,准确度会高很多。远程对web服务器进行压力测试,往往效果不理想(因为网络延时过大或带宽不足)

下载安装: 
http://mirror.bit.edu.cn/apache//httpd/binaries/win32/?C=M;O=A 
找到 httpd-2.2.21-win32-x86-no_ssl.msi

参数文档: 
http://httpd.apache.org/docs/2.2/programs/ab.html

运行: 
在Windows系统下,打开cmd命令行窗口,定位到apache安装目录的bin目录下 
cd C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin

键入命令: 
ab -n 800 -c 800  http://192.168.0.10/ 
(-n发出800个请求,-c模拟800并发,相当800人同时访问,后面是测试url)

ab -t 60 -c 100 http://192.168.0.10/ 
在60秒内发请求,一次100个请求。 
  
//如果需要在url中带参数,这样做 
ab -t 60 -c 100 -T "text/plain" -p p.txt http://192.168.0.10/hello.html 
p.txt 是和ab.exe在一个目录 
p.txt 中可以写参数,如  p=wdp&fq=78

 
结果参数解释: 
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 192.168.0.10 (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 
Finished 800 requests

Server Software:        Microsoft-HTTPAPI/2.0 
Server Hostname:        192.168.0.10 
Server Port:            80

Document Path:          / 
Document Length:        315 bytes       HTTP响应数据的正文长度

Concurrency Level:      800 
Time taken for tests:   0.914 seconds    所有这些请求处理完成所花费的时间 
Complete requests:      800             完成请求数 
Failed requests:        0                失败请求数 
Write errors:           0                
Non-2xx responses:      800 
Total transferred:      393600 bytes     网络总传输量 
HTML transferred:       252000 bytes     HTML内容传输量 
Requests per second:    875.22 [#/sec] (mean) 吞吐量-每秒请求数 
Time per request:       914.052 [ms] (mean)  服务器收到请求,响应页面要花费的时间 
Time per request:       1.143 [ms] (mean, across all concurrent requests) 并发的每个请求平均消耗时间 
Transfer rate:          420.52 [Kbytes/sec] received 平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题

网络上消耗的时间的分解: 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:        0    1   0.5      1       3 
Processing:   245  534 125.2    570     682 
Waiting:       11  386 189.1    409     669 
Total:        246  535 125.0    571     684

整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间 
其中 50% 的用户响应时间小于 571 毫秒 
80 % 的用户响应时间小于 652 毫秒 
最大的响应时间小于 684 毫秒 
Percentage of the requests served within a certain time (ms) 
  50%    571 
  66%    627 
  75%    646 
  80%    652 
  90%    666 
  95%    677 
  98%    681 
  99%    682 
100%    684 (longest request)

原文地址:https://www.cnblogs.com/lhxsoft/p/11751869.html

时间: 2024-10-04 13:23:11

并发负载压力测试的相关文章

Apache ab并发负载压力测试

由于现在网站都需要能够承受高并发要求的能力,所以当我们写完代码后,如果需要上线,最好都经过压力测试后,这样比较好 运行: 在Windows系统下,打开cmd命令行窗口,定位到apache安装目录的bin目录下 cd C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin 键入命令: ab -n 800 -c 800  http://192.168.0.10/ (-n发出800个请求,-c模拟800并发,相当800人同时访问,

[转]性能测试(并发负载压力)测试分析-简要篇

在论坛混了多日,发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试,但多数人对怎样去分析工具收集到的测试结果感到无从下手,下面我就把个人工作中的体会和收集到的有关资料整理出来,希望能对大家分析测试结果有所帮助. 分析原则:    • 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)    • 查找瓶颈时按以下顺序,由易到难.    服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库

Tsung:开源多协议分布式负载&压力测试工具

Main features High Performance: the load can be distributed on a cluster of client machines Multi-protocols using a plugin system: HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP , XMPP/Jabber, BOSH, MQTT and AMQP are currently supported. SSL is also sup

性能测试(并发负载压力)测试分析(转载)

分析原则: " 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点) " 查找瓶颈时按以下顺序,由易到难. 服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句.数据库设计.业务逻辑.算法等) 注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度.对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数.数据量)下,系统的硬件瓶

azure存储并发写 压力测试

之前的测试都是针对比较大的文件,由于带宽的限制所以无法更好的测出azure存储在写入方面的并发能力.这次测试主要考察一下azure在写入并能力,主要测试写入1K,2K,4K的文件.azure的api损耗还是比较高的,所以在现有测试资源环境最大只能达到1W多个文件写入.不过这个量对于大部分中小型企业来说已经是相当可观的数字.

十大抢手的网站压力测试工具

两天,jnj在本站发布了<如何在低速率网络中测试 Web 应用>,那是测试网络不好的情况.而下面是十个免费的可以用来进行Web的负载/压力测试的工具,这样,你就可以知道你的服务器以及你的WEB应用能够顶得住多少的并发量,以及你的网站的性能.我相信,北京奥组委的订票网站的开发团队并不知道有这样的测试工具. Grinder –  Grinder是一个开源的JVM负载测试框架,它通过很多负载注射器来为分布式测试提供了便利. 支持用于执行测试脚本的Jython脚本引擎HTTP测试可通过HTTP代理进行

[网站安全] 十大抢手的网站压力测试工具

参考:http://www.oschina.net/news/30374/10-free-tools-to-loadstress-test-your-web?from=rss 两天,jnj在本站发布了<如何在低速率网络中测试 Web 应用>,那是测试网络不好的情况.而下面是十个免费的可以用来进行Web的负载/压力测试的工具,这样,你就可以知道你的服务器以及你的WEB应用能够顶得住多少的并发量,以及你的网站的性能.我相信,北京奥组委的订票网站的开发团队并不知道有这样的测试工具. Grinder 

十个免费的Web压力测试工具

两天,jnj在本站发布了<如何在低速率网络中测试 Web 应用>,那是测试网络不好的情况.而下面是十个免费的可以用来进行Web的负载/压力测试的工具,这样,你就可以知道你的服务器以及你的WEB应用能够顶得住多少的并发量,以及你的网站的性能.我相信,北京奥组委的订票网站的开发团队并不知道有这样的测试工具. Grinder –  Grinder是一个开源的JVM负载测试框架,它通过很多负载注射器来为分布式测试提供了便利. 支持用于执行测试脚本的Jython脚本引擎HTTP测试可通过HTTP代理进行

【转】十大抢手的网站压力测试工具

两天,jnj在本站发布了<如何在低速率网络中测试 Web 应用>,那是测试网络不好的情况.而下面是十个免费的可以用来进行Web的负载/压力测试的工具,这样,你就可以知道你的服务器以及你的WEB应用能够顶得住多少的并发量,以及你的网站的性能.我相信,北京奥组委的订票网站的开发团队并不知道有这样的测试工具. Grinder –  Grinder是一个开源的JVM负载测试框架,它通过很多负载注射器来为分布式测试提供了便利. 支持用于执行测试脚本的Jython脚本引擎HTTP测试可通过HTTP代理进行