工具

ab

特点
单线程

作者：玩家翁伟链接：www.zhihu.com/question/19… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

工具
最常见的web压测工具是ab - apache benchmark；我偶尔会拿ab来做简单的快速测试。但做严格的测试时，ab就会显得非常不合适。

首先，ab是单线程程序，只能利用单一CPU，在给性能好的服务器端应用做压测时，往往跑ab的测试机负荷满了；而服务器应用的性能还绰绰有余。

这在测试默认启用多核的go程序是非常常见的。

建议至少使用techempower所用的wrk替代ab；wrk默认可以利用单一CPU的多个核。

其次，ab仅能是对单一url进行压测，而当我们仅仅只是反复测试单一URL时，出来的测试结果往往不能体现真实的压力场景。

比方说，应用程序反复查询、返回同一个账号的资料，跟随机查询、返回十万个用户是不一样的；前者的返回结果很容易就被数据库、应用给“缓存”掉。而对于被严重“缓存”的性能测试结果，并不能很好的反应真实场景下的性能表现。

如果要模拟真实的压测场景，我会推荐使用siege，siege的有多个参数方便模拟真实压力场景：

-f FILE, --file=FILE参数指定一个输入文件，在文件中指定多个不同的url，然后对这多个url进行压测。 -i, --internet则是指定随机发送输入文件中的url wrk也支持使用lua脚本去生成压测的请求，siege上面能做的，wrk肯定也可以通过自己编写脚本去实现。

jmeter

开源jmeter。最佳实践。

目前做网站压力测试：权威的商业软件还是LoadRunner。

开源使用范围最广的是Jmeter，其他常用还有Gatling、Tsung，目前被各大电商修改的开源Grinder。

最简单的ab工具、Seige等等。

在线压测的话OneAPM的CPT比较专业的，目前真正能做到云压测百万QPS的。

作者：高海强链接：www.zhihu.com/question/20… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

优点
推荐Apache JMeter，开源好用。
亮点1：基于java，所以跨平台。
亮点2：可以自定义load test的流程，包括load test前的预热阶段，load test后performance情况的各种图表展示。service大多有cache，如果在cache没有数据的情况下做压力测试，就不能反应实际情况，预热阶段干的就是往cache里塞历史数据。
亮点3：在输入方面，支持对资源文件的简单解析。比如把前一天的服务器日志作为输入，通过定义简单的脚本，把日志中所有出现过的用户id都找出来，再作为参数传给load test的url，这样就可以模拟online情况的压力测试了。

作者：李潇链接：www.zhihu.com/question/19… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

商业软件

loadrunner

wetest腾讯

想要实现百万级服务器并发的话，首选要能够达到足够量的压力源。

推荐一款简单易用的压测工具：腾讯WeTest - 压测大师

这款工具的特点有：

由腾讯云提供压力源，无需额外配置压力机。云端压力稳定、无上限。一分钟完成用例配置，可模拟复杂业务场景，分配压力比重，支持瞬时并发，均匀压力、长时间稳定性测试。性能测试数据图表可视化展示，监控核心性能指标如 TPS、响应时间、 CPU、内存、磁盘IO、网卡负载压力机性能监测等。希望这款工具可以帮您解决百万级的服务器并发压力测试。

作者：腾讯WeTest 链接：www.zhihu.com/question/47… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

参考

coolshell.cn/articles/25…

目标

三个指标数据

性能测试最关注的三个指标分别是：响应时间、TPS、资源使用情况。

就是要知道单机qps是多少？
瓶颈
我会认为，压测的目的是在于找到系统的瓶颈，一定是要确定系统某个方面达到瓶颈了，压力测试才算是基本完成。

当我们说系统可以支撑某某压力时，一定要同时能够清楚的说出系统的瓶颈是在哪里；也就是说，当瓶颈得到改善的时候，系统的性能可以得到提高。

对于web应用，系统的瓶颈往往会是数据库；系统满负荷运作的时候，数据库的CPU或者是磁盘IO是否跑满了？

如果没有，那么很可能是说明瓶颈是在别的地方；如果是在应用，那么应用服务器的CPU、内存、IO等等也应该有所体现。

找到系统的瓶颈，是需要反复做不同测试、优化，然后分析出来的。

对于一些性能有高要求的公司，比方说七牛云，据说他们只接受网络IO这一瓶颈，压测的时候，是一定要把千兆网卡跑满，才算是性能达标；如果网卡没跑满，那就说明瓶颈是在别的地方，要去不断优化，直到网卡的物理限制成为系统的瓶颈。

作者：玩家翁伟链接：www.zhihu.com/question/19… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

如题说，一般做压力测试主要以协议测试为主。

分为以下几点：

确定下web应用的协议，如果只是web服务器的话一般用http或者https协议，如果有APP客户端的话还要确定下其采用的协议。预估下系统的服务能力，如果不清楚的话可以采用逐步加压的方式进行探测。采用压测工具启动机器人对服务器进行施压，观察一些重点指标（TPS，响应时间，带宽流量，CPU，内存，DB）等。如果硬件性能都还OK的话，可以逐步增加压力。如果测试过程中发下某个或者多个指标飙升（CPU达到90%以上，内存占用很高等），可能触及瓶颈了。对于一些IO较大的请求也要观察下带宽的占用情况（可能逻辑服务器毫无压力，但是带宽已经早就满了）。对于压测过程也需要时刻关注db的性能，慢查询是否变多。优化的话可以根据实际的服务器瓶颈，进行针对性的优化。干货传送门：浅谈服务器性能测试的全生命周期——从测试、结果分析到优化策略 - 腾讯WeTest

另外推荐下腾讯WeTest自研的性能测试工具 - 压测大师，一分钟完成用例配置，无需维护测试环境，支持http/https协议、API接口、网站等主流压测场景。

作者：腾讯WeTest 链接：www.zhihu.com/question/19… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

分层

1.各个层，是如何测试的。而且方法有点不一样。 2.以及解决方法是怎么样的。

作者：匿名用户链接：www.zhihu.com/question/20… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

从压力测试来说，网站的压力分几层。 web server 层（tomcat/nginx/iis），这个稍微简单一些，用脚本（curl/python）或者小工具（apache-utils），制造高并发的get/post请求到服务器看响应时间。优化的手段一般是做网页静态化减少与应用层的数据请求交互，这也是大部分网站做的事情。

应用层，这个涉及业务链的性能，就需要写复杂一点的脚本或者用loadrunner一类的工具，把整个业务场景涉及的流程都写好，然后跑多并发的用户去测试应用对请求的处理和响应时间。优化的手段就复杂一些了，需要根据测试的结果优化业务处理的流程或者数据处理的方式，这种优化涉及架构，优化代码处理的cpu占用时间，优化数据的内存占用，选择一些查找性能比较好的数据结构，比较底层。

数据层，直接测数据库性能的业务不多，一般都与业务关联，用脚本或者loadrunner一类的工具，对一些需要写入/读取数据的业务施加一个高并发的压力，看数据库的处理写入/读取时间。涉及这个层次的优化与应用层的优化比更多的是考虑数据库的性能，比如做数据库集群，做数据库写入的缓存队列，数据库缓存到内存中。

磁盘IO层，这个一般都不会考虑，已经不属于网站功能的测试范围了，只有真的是碰到网站访问量巨大，写入和读取的数量非常非常大的时候才会考虑到，图片/js/css，数据库写入/读取等磁盘IO请求已经繁忙到服务器硬件都崩溃的情况，优化手段无非就是根据读取或写入的实际情况上高性能的文件服务集群（TFS），用SSD,做磁盘阵列，有钱的考虑EMC这类的高级存储服务器。//分布式文件存储

模拟线上情况模拟线上用户

作者：王洋链接：www.zhihu.com/question/19… 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

本人做web端的压力测试与开发已经有一年多时间，关于web端的压力测试，主要有以下经验给大家分享： web端的压力测试主要包括，系统高峰的使用人数，各事务的操作频率，收发包情况，TPS指标等。一个web站点开发完上线前，我们必须要做好压力测试，压力测试通过模拟线上用户逐步增压，能够很好地反应我们服务器的性能，它的好坏会直接决定线上用户的数量。

压力测试的一般方法大致是这样：通过设计各种综合测试场景，模拟线上用户的使用情况，逐步增大压力，监控在测试过程中，系统各性能指标在这种压力下是否能保持正常数值，事务响应时间是否会出现大波动或逐步增长，以及系统会在大压力情况下出现宕机，应用服务终止等不稳定情况。通过上述压力测试，定位出性能拐点位置，并确定并发用户的最大数量。

我们做压力测试低成本的方法就是使用一些现有的已开发好的工具，如开源的ab，jmeter, 付费的Load Runner等。这里，我强烈推荐大家一个市面上新出的而且很好用的性能测试工具(WeTest服务器性能)，我目前一直使用的也是它。该工具是腾讯wetest团队出品，使用起来很简单方便，但测试功能相当强大，据说能提供10w+以上的并发量，定位性能拐点，测出你的服务器最大并发不再是问题。大家需要测压力测试的话，可以自己去体验，很容易操作，这里给出一些我测试的截图：

单个机器的极限？需要多少个机器？

压力测试的目的

搞懂为什么要压力测试，这样在压力测试的时候才不会事倍功半，毕竟压力测试一次的成本还是蛮高的。压力测试其实有两个目的，一是测试应用在高并发情况下是否会报错，进程是否会挂掉；二是测试应用的抗压能力，预估应用的承载能力，为运维同学提供扩容的依据。

第一点很好理解，做好这一点就可以保证上线之后不出问题了。解释下第二点，我们都知道就是架构设计的再优秀，代码写的再好，应对高并发单实例始终是有限的。所以通常是在满足第一点的前提下，再根据可能到来的高并发压力来计算需要多少实例来承载，而这就需要我们压出极限。

解决方案

wetest.qq.com/lab/view/?i… //很好很全

维度

1.线程数量
即是否单线程多线程？

2.接口数量
就单个接口，还是多个接口？

3.全链路压测

4.测试时间长短即观察长时间运行的结果。

第一次压力测试
接口开发完成之后就可以进行第一次压力测试。这一次压力测试可以简单压一下，在本机进行就可以。压力测试的目的是检查代码在高并发下是否会报错。另外，编译型语言要观察是否存在内存泄漏，比如golang。

因为本机性能有限，一般来说按照100、200、300、500进程数进行压力测试，压到500如果没有报错就可以进行疲劳测试，观察内存占用。

第二次压力测试
一般来说是不可能在线上进行压力测试的，所以一般都是在仿真环境。所以这就对仿真环境提出了更高的要求，有条件的要保证仿真和线上配置一致。次之也要和线上成比例，这样可以方便后续评估计算。

这一次压力测试重点是压极限。需要特别要注意，这里的极限不是数据库极限，不是Redis极限，而是是指应用服务器的极限承受能力。上面已经说了，压极限是为了给运维同学提供扩容的参考，所以我们要做的是压到服务器的承受极限，看下到底能够承受多大的并发。假设现在线上是双实例8C8G，仿真双实例4C4G。

比如说我们我们压出仿真的极限承受能力是1000，那么我们就可以预估线上能够承受2000并发。比如我们预估接下来我们会迎来一次5000并发的冲击，那么运维同学就可以根据这些数据来评估出相应的扩容方案。

apache benchmark

安装-mac
gist.github.com/safecat/f45…

我电脑，已经安装了

入门
www.petefreitag.com/item/689.cf…

实战 n //总共请求数量 c //每次并发请求数量

 promote:~ gongzhihao$ ab -n 1 -c 1 http://www.yahoo.com/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.yahoo.com (be patient)...
..done


Server Software: ATS
Server Hostname: www.yahoo.com
Server Port: 80

Document Path: /
Document Length: 8 bytes

Concurrency Level: 1
Time taken for tests: 1.570 seconds
Complete requests: 1
Failed requests: 0
Non-2xx responses: 1
Total transferred: 621 bytes
HTML transferred: 8 bytes
Requests per second: 0.64 [#/sec] (mean)
Time per request: 1570.217 [ms] (mean)
Time per request: 1570.217 [ms] (mean, across all concurrent requests)
Transfer rate: 0.39 [Kbytes/sec] received

Connection Times (ms)
              min mean[+/-sd] median max
Connect: 1261 1261 0.0 1261 1261
Processing: 309 309 0.0 309 309
Waiting: 307 307 0.0 307 307
Total: 1570 1570 0.0 1570 1570
promote:~ gongzhihao$

promote:~ gongzhihao$ ab -n 100 -c 10 http://www.yahoo.com/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.yahoo.com (be patient)...apr_pollset_poll: The timeout specified has expired (70007) //超时
Total of 94 requests completed //已经完成94个请求
promote:~ gongzhihao$

promote:~ gongzhihao$ ab -n 10 -c 2 http://www.yahoo.com/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.yahoo.com (be patient)...apr_pollset_poll: The timeout specified has expired (70007)
Total of 9 requests completed
promote:~ gongzhihao$

promote:~ gongzhihao$ ab -n 10 -c 2 http://www.yahoo.com/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.yahoo.com (be patient)...apr_pollset_poll: The timeout specified has expired (70007)
Total of 9 requests completed
promote:~ gongzhihao$ ab -n 5 -c 2 http://www.yahoo.com/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.yahoo.com (be patient).....done


Server Software: ATS
Server Hostname: www.yahoo.com
Server Port: 80

Document Path: /
Document Length: 8 bytes

Concurrency Level: 2 //一次的并发数量是2
Time taken for tests: 6.091 seconds
Complete requests: 5
Failed requests: 0
Non-2xx responses: 5
Total transferred: 3105 bytes
HTML transferred: 40 bytes
Requests per second: 0.82 [#/sec] (mean) //rps是1/s
Time per request: 2436.510 [ms] (mean) //每个请求2s
Time per request: 1218.255 [ms] (mean, across all concurrent requests)
Transfer rate: 0.50 [Kbytes/sec] received

Connection Times (ms)
              min mean[+/-sd] median max
Connect: 249 706 952.5 308 2409
Processing: 256 862 783.5 967 1813
Waiting: 256 295 22.7 306 313
Total: 513 1568 1585.6 1245 4223

Percentage of the requests served within a certain time (ms)
  50% 621
  66% 1869
  75% 1869
  80% 4223
  90% 4223
  95% 4223
  98% 4223
  99% 4223
 100% 4223 (longest request)
promote:~ gongzhihao$

百度的速度，明显更快。因为是国内的。

promote:~ gongzhihao$ ab -n 5 -c 2 http://www.baidu.com/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.baidu.com (be patient).....done


Server Software: BWS/1.1
Server Hostname: www.baidu.com
Server Port: 80

Document Path: /
Document Length: 156826 bytes

Concurrency Level: 2
Time taken for tests: 0.745 seconds
Complete requests: 5
Failed requests: 4
   (Connect: 0, Receive: 0, Length: 4, Exceptions: 0)
Total transferred: 789628 bytes
HTML transferred: 783634 bytes
Requests per second: 6.71 [#/sec] (mean)
Time per request: 298.149 [ms] (mean)
Time per request: 149.074 [ms] (mean, across all concurrent requests)
Transfer rate: 1034.55 [Kbytes/sec] received

Connection Times (ms)
              min mean[+/-sd] median max
Connect: 45 48 4.7 46 56
Processing: 162 224 89.0 204 379
Waiting: 47 88 80.1 56 231
Total: 208 272 87.9 255 424

Percentage of the requests served within a certain time (ms)
  50% 245
  66% 264
  75% 264
  80% 424
  90% 424
  95% 424
  98% 424
  99% 424
 100% 424 (longest request)
promote:~ gongzhihao$

单线程

为什么说是单线程？因为只有一个线程在发送请求。
1.一次发送10个请求 //一次循环发送10个请求
2.总共发送100个请求 //for循环实现，每次发送10个请求，循环10次

输入和输出

1.输入
url 并发数量 //比如，url 100

2.输出
rps //比如，300/s

每个请求的时间 //几毫秒

每个阶段花费的时间

1.建立连接的时间
2.写数据的时间
3.读数据的时间