一、jmeter和ab对比：
1、jmeter能够把服务器性能极限，压出来，但是ab并不能。
理由：同样并发数，比如1000并发，jmeter可以把cpu压满。ab不能。
2、jmeter统计的吞吐量不准确。ab比较准确。
理由：我们直接在服务器程序里添加一个请求计数，然后每秒取一次计数。
结果，这个计数和ab的qps几乎一样。
而jmeter的吞吐量，远远小于它。
@GetMapping("test2")
public Sbtest1 test2() throws InterruptedException {
atomicLong.incrementAndGet();
Sbtest1 list = sbtest1Service.list();
return list;
}
@Scheduled(cron = "0/1 * * * * ?")
public void test3(){
long l = atomicLong.get();
System.out.println(l - start);
start = l;
}
用ab，1000个并发，1万个请求。qps是2000，程序中打印的也是2000。cpu压到85%。
ab -n 100000 -c 1000 http://localhost:8080/test/test2
用jmeter，1000个并发，10秒到达顶峰，500次循环。吞吐量只显示1000。
但是程序打印有将近7000，而且cpu压到100%。
再查看数据库qps统计：jmeter压测的时候，数据库qps到了8000。
综上：准确的数字，应该是服务器的极限qps是6000。
但是，我们使用sysbench，测试这条select语句，得到的mysql的qps是1万5。所以，这个服务器，并没有把数据库的极限能力消耗完
所以，如果考虑扩容，那么应该，选择两台，应用服务器，而不需要对mysql扩容处理。
二、测试nginx。
nginx 部署在windows上。同一个配置文件。
并发：1000。
qps：4千
ab -n 100000 -c 1000 -k http://127.0.0.1:80/
部署在windows开的linux虚拟机上。
并发：1000。
qps：2万
可见: nginx如果部署在windows上，是很划不来的。
配置文件。
worker_processes 8;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
三、联合压测
nginx压测2万。
tomcat服务器压测3500。
当nginx和tomcat在同一个服务器上时，tomcat qps达到3000多。 整个请求qps 3000。
这是正常的。
当nginx和tomcat在不同服务器上时。
tomcat qps 1万。
nginx qps 1万5到2万。
跨nginx访问的时候。
tomcat qps 100。
后来经过排查，是网络原因，因为我的nginx是部署在虚拟机上的，虚拟的网络有点问题。
同时，也得出一个结论，网络带宽对服务器，吞吐量影响是非常大的。
其实，更细致的压测，磁盘，内存，cpu，网络，然后到应用，找到各个的极限值，然后进行评判，到底是哪里存在问题，哪里需要扩大性能。
四、最贴近真实使用的qps
实际使用的时候，网络因素肯定要考虑到。
那么使用比如：腾讯的压测大师，阿里的pts，这种测试，几乎就是真正的生产的时候的数据了。
因为，它会从全国各地各个节点，发送请求，几乎和真实的用户请求一致。
五、基准测试在生产环境中的使用。
一个业务上线，评估一下，这个业务是否能稳定运行。
1、评估一下qps。
可以通过过往的经验评估。
1.1、所以，对于平时的qps的统计是很有必要的。比如阿里的sentinel。
1.2、凭经验估算，问产品，比如，每天的访问量是多少，2 8法则，大概峰值访问量是多少，然后估算出峰值qps。当然这个不准，跟业务关联。
2、然后根据压测数据，评估一下，我们的应用是否上线之后可以稳定运行。
这么多qps，最后落到缓存的qps有多少，落到数据库的qps有多少。
压测一下mysql是否能够支持这个并发（一般没问题，不可能落到mysql的qps有3000个以上），mysql不行则加主从（加主从要考虑主从延迟导致的问题），或者换硬件，用机械磁盘什么的。
压测一下redis是否够支持这个并发，如果不够，则加机器。并发不够则加主从。
容量不够则加大maxmemory，加大系统内存，再不行则做集群。
压测一下服务层是否够支持这些并发。（不够则加服务器）
压测一下网关路由层。nginx，gateway，zuul等等，网关路由层不可能支持不了吧，有那么大并发吗，支持不了就考虑lvs，dns轮询，f5什么的。
当对各个环节的极限性能都心中有数。
再各个环节联调压测一下，结合网络带宽，最终解决了各个环节的性能瓶颈之后，得到一个准确的整个请求链的qps。