本文详细介绍了使用JMeter进行性能测试的过程，包括并发用户数、响应时间、吞吐量等关键指标的分析。同时，探讨了并发与负载的区别，并提供了实际测试案例，展示了不同负载下系统资源的使用情况。此外，还提到了Tomcat服务器的参数调优和监控工具的使用，以及微服务项目性能测试的策略。文章最后分享了压力测试报告的编写要点和性能调优的建议。
https://www.cnblogs.com/canglongdao/p/12606952.html
https://blog.csdn.net/qq_25305833/article/details/122018709?spm=1001.2014.3001.5501
1、指标：多快好省
并发数与tps是两个东西关系如下图：
1.1、响应时间
1.2、并发用户数
负载：只加载多少个用户（线程）（这个不加定时器）
并发：是同时提交，并发是负载里的一种特殊负载，这种需要用到集合点（定时器）
要不要加定时器，不是我决定的，是具体的场景决定的。如只有负载没有并发的场景，如有负载且有并发的场景。
说一个系统某个功能可支持的并发数是多少，指的是cpu,内存，IO,响应时间，错误率控制在行业标准范围内或指定的范围内的前提下支持的用户数。不可以说你用jmeter并发5000，但错误率是100%，或错误率是0但响应时间是几分钟,或错误率是0但cpu是95%以上，或..........类似这些结果也可以算支持5000并发，不可以这样说的。
平均并发用户数
一、经典公式1：
一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。
那么，
平均并发用户数为：C = 4004/8 = 200
并发用户数峰值为：C‘ = 200 + 3*根号200 = 243
举例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为（朝九晚五）：
n = 1700000.50.7/5 = 11900--------/5应该是因为一周上班5天，除以5可以得到平均一天的登陆人数。
C= 119005/60/8 = 124--------5/60是为了把5分钟转为小时即0.083小时
吞吐量计算为：F = Vu * R / T 单位为个/s
F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间
二、通用公式2：
对绝大多数场景，我们用（用户总量/统计时间）影响因子（一般为3）来进行估算并发量。
比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为5000080%/（36060）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s3s=12，当然影响因子可以根据实际情况增大！
三、根据PV计算公式：
比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：
1000w80%/(93600)=246.92个/s,取经验因子3，则并发量应为：
246.92*3=740
四、根据TPS估计：
公式为 C = (Think time + 1)*TPS
五、根据系统用户数计算：
并发用户数 = 系统最大在线用户数的8%到12%
狭义并发
即所有用户在同一时间做同一件事情，这种操作一般针对同一类型的业务（大家一起购买物品，都是购买，但买的东西可以不同）或者所有用户进行完全一样的操作（大家一起秒杀同一个物品），目的是测试数据库和程序对并发操作的处理。狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试；（单一测试场景）
广义并发
广义的并发，即多个用户对系统发出了请求或进行了操作，但这些请求和操作是不同的。对整个系统而言，仍然有很多用户同时进行操作。广义并发不限制对系统的请求操作，多适用于稳定性测试；（混合测试场景）
1.3、吞吐量
1.4、系统性能计数器（资源利用率 ）
资源利用率
资源利用率是指系统资源的使用程度，比如服务器（网络以及数据库）的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。
除了上述资源，我们还应该考虑数据库连接池使用情况，JVM内存使用情况，sql执行效率等。
5、性能测试的类型
随着压力不断增长，实测系统的资源会不断被消耗，TPS值会因为这些因素而发生变化，并且符合一定的规律。
上图：
X轴是VU虚拟用户的数量；
Y轴是TPS值；
a点：性能期望值
b点：高于期望值，系统资源处于临界点
c点：高于期望值，拐点
d点：超过最大负载，系统崩溃
2、思考时间
3、性能测试、负载测试、压力测试
简单总结：
性能测试是为了获取或验证系统在各负载下的性能指标而进行测试。其中负载测试只是性能测试的一种具体方式或手段。而压力测试是负载测试的一种，其实就是强负载下的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。。
负载测试
模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
压力测试
是在**强负载（大数据量、大量并发用户等）**下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使用或系统出错的概率比较低，可能一个月只出现一次，但在高负载（压力测试）下，可能一天就出现，从而发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这一点，某个电子商务网站的订单提交功能，在10个并发用户时错误率是零，在 50个并发用户时错误率是1%，而在200个并发用户时错误率是20％。
负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或行为来发现问题，从而为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的一部分。但它们两者的目的是不一样的，负载测试是为了发现缺陷，而性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，而是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所属的一种技术，即性能测试使用负载测试的技术、使用负载测试的工具。性能测试要获得在不同的负载情况下的性能指标数据。
通过负载测试和压力测试都可以获得系统正常工作时的极限负载或最大容量。容量测试，自然也是采用负载测试技术来实现，而在破坏性的压力测试中，容量的确定可以看作是一种副产品——间接结果。
简单总结如下
负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、压力测试所采用。
性能测试是为获取或验证系统性能指标而进行测试。多数情况下，性能测试会在不同负载情况下进行。
压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。
4、自己关于jmeter的测试截图（每个场景只测试了2分钟）
maxThreads ：客户请求最大线程数
acceptAccount： 监听端口队列最大数，满了之后请求会被拒绝（不能小于maxSpareThreads ）
下图的1、2都是设置了集合点的。且也只是测试2分钟内的数据
5、我电脑的jmeter可以产生多少个负载？5000个？
测试的时候并没有加定时器做并发，只做了负载。
6、我电脑的jmeter可以产生多少个并发？5000个？
其实只做5000的负载（5000个线程一直循环不断发出请求），要比5000的负载加集合点设置5000的并发要累。因为只有负载时是不断发出请求的，设置了集合点后，则组队够了5000才会发出请求（即服务器要把5000个请求都响应回来后jmeter才会有5000个线程释放，才够组队发出下一次并发），所以不那么累。所以说可以创建5000负载的机器，一定可以做5000的并发。
6、一台电脑的jmeter最多只可以产生2000的负载。
下图就是一台电脑只开一个jmeter设置2500负载的cup监控图，从图中可以看到1分30秒后就长期100%了。
下图是加了同步定时器且它所设置的数量与总线程数量一样或接近时的cup监控图。像设置了定时器的cup是不会持续的高占用的，而是一波一波的形态。
但如果没有设置定时器则cup就会是持续高占用了，因为它不用组队，不用指定凑够多少个线程才会发出请求，而是只要有空闲的线程就要发请求，所以一直会很忙。
7、千万级的并发应该怎么测试（自己的猜想）
说明：首先要明确这个千万级并发是广义上并发的还是夹义上的并发。
广义上的千万级指的是：就用一千万来说吧，500万人在下单，200万人在看我的订单，200万人在看商品列表页面，100万人在看订单详情页面。（这种是不设置有集合点的），比如并发50个用户,持续运行10分钟，但不设置集合点
夹义上的千万级指的是：就用一千万来说吧，1000万人都在下单购买同一件商品，或1000万人都在同时访问同一个商品的详情页面。（这种是设置有集合点的），比如并发50个用户,持续运行10分钟，设置集合点为50个线程为一组
问题：如何知道我的系统的某个页面或划某个功能是否支持1000万的并发？要多少台什么样配置的服务器才可以达到某个页面或划某个功能是否支持1000万的并发？
答：方案一：真的发出1000万模拟请求进行测试，具体如下：用jmeter进行负载测试，逐步加大负载（线程数）。把当前电脑jmeter的内存分配到最大，最多只可以模拟10000个并发，那么需要需要对jmeter进行集群。得到一台电脑可以模拟出多少个并发，然后用1000万除以单台电脑的并发量就可以获取多少台电脑了。
方案二：不需要发出1000万模拟请求进行测试。用做实验的思想进行测试（像国家做火箭一样，先做小实验得到规律，再估算出做大型的火箭需要多少材料）。如目前你生产环境的配置一台是64G内存、2CPU、8TB硬盘。比如你可以用32G内存、1CPU、4TB硬盘环境进行测试（或再低的配置进行测试）。如果知道你的项目对cpu和硬盘的要求不高，只对内存要求高，即内存才是木桶短板，这就更好办了，准备好2G、4G、8G的内存条，分别对2G、4G、8G的内存条下的系统用jmeter进行测试，看看并发数据的变化是怎样的比例，这样就可以推测出生产环境的并发量是多少了。就像曹冲称象那样，用一堆石头和船就要以称出大象的重量了（我再升级了一下这个故事，如果船每个高度的排水都是一样的，那么就不用一堆石头了,用一块几十斤的石头就可以了，看一块石头船会下沉多少高度，再计算一下就可以知道大象的重量了）。
8、tomcat吞吐量为1500左右，默认线程数是200
通过测试知道了我电脑的tomca8服务器运行简单javaweb项目（不连接数据库不设置睡眠，只有一个接口返回字符串），可以支持700个并发保持2分钟错误率为0（没有测试过更长时间），如果发起800个并发那么在1分左右后就会出现错误率了。同时知道这样的简单javaweb项目吞吐量大概是1500左右。
9、tomcat中的参数调优
tomcat 的Connector配置如下
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="800" acceptCount="1000"/>
其中最后两个参数意义如下：
maxThreads：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200
acceptCount：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100
maxIdleTime：最大空闲时间，超过这个空闲时间，且线程数大于minSpareThreads的，都会被回收，默认值1分钟（60000ms）；
minSpareThreads：最小空闲线程数，任何情况都会存活的线程数，即便超过了最大空闲时间，也不会被回收，默认值4；
maxSpareThreads：最大空闲线程数，在最大空闲时间（maxIdleTime）内活跃过，此时空闲，当空闲时间大于maxIdleTime则被回收，小则继续存活，等待被调度，默认值50；
maxThreads：最大线程数，大并发请求时，tomcat能创建来处理请求的最大线程数，超过则放入请求队列中进行排队，默认值为200；
acceptCount：当最大线程数（maxThreads）被使用完时，可以放入请求队列排队个数，超过这个数返回connection refused（请求被拒绝），一般设置和maxThreads一样，不过
这个具体需要根据自己的应用实际访问峰值和平均值来权衡，默认值为100；
connectionTimeout：网络连接超时，假设设置为0表示永不超时，这样设置隐患巨大，通常可设置为30000ms，默认60000ms。
Windows Tomcat每个进程允许maxThreads（最大线程数）2000
Linux Tomcat每个进程允许maxThreads（最大线程数）1000
10、Tomcat8w.exe的运行问题及VisualVM的使用
结果在tomcat8/bin下电极startup可以启动tomcat，http://localhost:8090/可以打开
但是不用startup，而是点击tomcat8w，点击start，无法启动，service
status一直显示stopped~
原因：
windows 服务内没有tomcat服务，所以无法启动
解决办法
cmd ->管理员权限运行
进入tomcat的bin目录下，我的是E:\tomcat\bin
可以先执行service.bat remove，是为了移除tomcat服务，防止出现问题
如果已经存在会移除，如果不存在会出现“指定服务未安装”
service.bat install , 添加 tomcat 服务
然后启动tomcat ，使用命令 start tomcat8w.exe，或者在E:\tomcat\bin下双击tomcat8w.exe
VisualVM在JDK6版本及以上已经自带这个应用。
位置：C:\Program Files (x86)\Java\jdk1.8.0_60\bin\jvisualvm.exe
在Windows环境下，在Tomcat8目录下tomcat8w.exe 用右键管理员权限打开，在启动界面添加以下参数
-Dcom.sun.management.jmxremote.port=9010
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
重启Tomcat8服务
在VisualVM添加JMX连接，localhost:9010。
成功添加本地Tomcat8，界面如下：
11、监控、分析、调优
11.0需求分析
11.1 了解性能指标
11.2 熟悉业务（项目性能场景提取）
11.3了解项目部署架构（才知道监控什么、分析什么、调优什么）
即是了解一个请求是出去到回来是怎么样的链路
11.4 开发脚本
脚本开发实践
优化调试
11.5搭建监控环境（在另一篇博客中）
Grafana+Node_exporter+Prometheus
11.6分析
切换到专门监控DB的页面：死锁问题、慢查询问题、分库分表是否合理的问题
目前DB有100万行数据，这个sql执行时查了99万行数据，如果DB中的数据有千万那这条sql会查得更慢。
11.8调优
优化后是原来的30倍，如果数据量更大，效果更明显，高并发时优化的倍数更大。
java的问题：1、是否有死锁（找到是哪个文件是的哪几行）、2、是否有堆内存的问题（找到是哪个对象）、3、GC回收是否正常 4、所引入的每三方jar是否是不支持高并发。
12、 压测计划制定
12、自动化压力测试
sed -i 就是直接对文本文件进行操作的
sed -i 's/原字符串/新字符串/' /home/1.txt sed -i 's/原字符串/新字符串/g' /home/1.txt
13、Jmeter性能监控技术有哪些
1、
用top来看的话是实时的，过了就没有了，当然可以写在日志文件中，但也不好看。
13.1 ServerAgent
但下图如果CPU使用率高的话，是看不出是哪个进程使用率的。所以这种监控的缺点是行明显的。太粗粒度了。
13.2 Nmon
nmon的缺点也明显，就是看不到趋势，要记录多个历史数据才可以看，不方便。
实时的：
按c再按m就可以看到如下界面，要按什么就出来什么
离线的：
13.3 Grafana
还有宝塔、APM等收费的监控平台
14、微服务项目性能测试实战（只是粗略地讲了一下）
jenkins+jmeter节点模式做分布式压测
20、分布式压测
jmeter远程分布式压力测试配置_虚幻如影的博客-CSDN博客
docker run -itd -p 1599:1599 -p 7000:7000 -p 5005:5005 --name jmeter_slave_2 java:8
slave的以下文件可以不用改，在启动时指定ip和指定两个端口就可以了
master的配置
master的配置：
去到bin录目下启动（localport这个端口要指定才可以的）：./jmeter-server -Djava.rmi.server.hostname=192.168.31.190 -Dserver_port=1599 -Dserver.rmi.localport=7000
master上写好的测试脚本交给slave执行
用脚本操作slave（如start/stop/restart）
20、压力测试报告（性能测试报告）
压力测试报告模板如下：
《xxxxxx》监测服务压力测试报告
文档修订记录
| 版本号 | 日期 | 修改人 | 摘要 |
| V1.0 | 2019年8月14日 | xxx | 初稿 |
内容目录
一、测试内容-------------------------------------------------------------4
二、测试方法-------------------------------------------------------------4
三、测试目标 -------------------------------------------------------------4
四、测试环境------------------------------------------------------------- 5
1.系统环境配置 -------------------------------------------------------5
2.测试客户端配置 ----------------------------------------------------5
3网络环境 ---------------------------------------------------------------5
4.测试时间-------------------------------------------------------------- 5
五、系统部署 ---------------------------------------------------------------5
六、测试说明------------------------------------------------------------------- 5
七、测试统计及分析------------------------------------------------------------- 6
八、结果------------------------------------------------------------------------- 10
九、结论及建议 ----------------------------------------------------------------10
1.结论：------------------------------------------------------------------ 10
2.建议：------------------------------------------------------------------ 10
一、测试内容
本次测试是针对《xxxx数字化营销》系统内的监测服务进行的压力测试,本次压测主要提取广告监测代码进行压测:广告监测服务。
二、测试方法
1.本次采用apache的开源测试工具jmeter，采用jmeter代理服务器录制脚本生成http请求脚本,并通过http协议get方式发送访问请求,收集服务器响应速度,服务器资源耗用情况。
2、安装启动JMeter,分别对以上页面进行压力测试分别测试50、100、500、1000个线程，即模拟这些数目的用户并发; Ramp-up period(inseconds)的值设为1(即1s启动50、100、500、1000并发访问),并发持续运行为10分钟。
3、测试指标提取:
| 测试项 | 并发数 | 线程组增量 | 持续运行时间 | 响应时间 | 成功率 | CPU使用率 | 内存使用率 |
|
广告监测服务 | 50 | 每秒增加10个 | 10分钟 | ≤5分钟 | 99% |
75% |
70% |
| 100 | 每秒增加100个 | 10分钟 | ≤5分钟 | 99% | |||
| 200 | 每秒增加200个 | 10分钟 | ≤5分钟 | 99% | |||
| 500 | 每秒增加500个 | 10分钟 | ≤5分钟 | 99% | |||
| 1000 | 每秒增加1000个 | 10分钟 | ≤5分钟 | 99% |
三、测试目标
一台广告监测服务器极限值
四、测试环境
1.系统环境配置
| 主机用途 | 机型/OS | 台数 | CPU/台 | 内存容量/台 | 对应IP |
| 应用服务器 | 1 | 2 CPU | 4GB | 公网：xxx 内网：xxx | |
| 数据库服务器 | 同上 | 同上 | 同上 | 同上 | 同上 |
2.测试客户端配置
| 主机用途 | 机型/OS | 台数 | CPU/台 | 内存容量/台 | 对应IP |
| 压力负载生成器 | xxx | 1 | 2 | 8G | xxx |
3网络环境
本次测试是在公网中进行的测试,更能模拟用户操作环境，可以会对压测造成影响。
4.测试时间
| 压测环境 | 测试人 | 测试时间 |
| 2CPU 4GB内存 | xxxxx | 2019年8月14 |
五、系统部署
系统已经经过开发人员部署在xxxxxx这台机子上,无需另外再次进行系统部署。
访问网址：XXXXX
六、测试说明
名词定义(时间的单位均为ms):
Samples – 本次场景中一共完成了多少个线程
Average – 平均响应时间
Median----50%请求的响应时间
90%Line----90%请求响应时间
95%Line----95%请求响应时间
99%Line----99%请求的响应时间
Min----最小的响应时间
Max----最大的响应时间
Error%----错误率=错误的请求的数量/请求的总数
Throughput----吞吐量即表示每秒完成的请求数
Received KB/sec----每秒从服务器端接收到的数据量
Sent KB/sec----每秒从客户端发送的请求的数量
七、测试统计及分析
压测场景：
1.输入URL：xxxxxxx
2.2CPU 4GB内存压力统计
1)50个线程组并发
聚合报告
并发50个用户,持续运行10分钟,完成1426013次访问请求,最小响应速度为0.004秒,最大为3.688秒,平均响应速度为0.02秒,与预期的快近4秒多,访问成功率100%,符合预期的需求。
系统资源耗用
从13：22开始压测,持续运行10分钟13：32结束，CPU使用率主要维持在45%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期小于70%,总体不符合需求。
2)100个线程组并发
聚合报告
并发100个用户,持续运行10分钟,完成1418887次访问请求,最小响应速度为0.004秒,最大为27.009秒,平均响应速度为0.042秒,与预期的快了近4秒多,访问成功率100%,符合预期的需求。
系统资源耗用
从13：37开始压测,持续运行10分钟13：47结束，CPU使用率主要维持在40%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期等于70%,总体不符合需求。
3)200个线程组并发
聚合报告
并发200个用户,持续运行10分钟,完成1452045次访问请求,最小响应速度为0.004秒,最大为367.546秒,平均响应速度为0.082秒,与预期的快4秒多,访问成功率100%,符合预期的需求。
系统资源耗用
从14：32开始压测,持续运行10分钟14：42结束，CPU使用率主要维持在65%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期70%略显偏高,总体不符合需求。
4)500个线程组并发
聚合报告
并发500个用户,持续运行10分钟,完成1334830次访问请求,最小响应速度为0.004秒,最大为417.365秒,平均响应速度为0.224秒,与预期的还快4秒,访问成功率99.99999%,符合预期的需求。
系统资源耗用
从14：48开始压测,持续运行10分钟14：58结束，CPU使用率主要维持在63%—87%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期70%略显偏高,总体不符合需求。
5)1000个线程组并发
聚合报告
并发1000个用户,持续运行10分钟,完成1289467次访问请求,最小响应速度为0.004秒,最大为597.21秒,平均响应速度为0.464秒,与预期的还快4秒,访问成功率99.99998%,符合预期的需求。
系统资源耗用
从15：08开始压测,持续运行10分钟15：18结束，CPU使用率主要维持在45%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期70%略显偏高,总体不符合需求。
针对广告监测动态统计
| 并发线程数 | #Samples | Average | 90%Line | Min | Max | Error% | Throughput |
| 50 | 1426013 | 20 | 11 | 4 | 3688 | 0.00% | 2374.7/sec |
| 100 | 1418887 | 42 | 22 | 4 | 27009 | 0.00% | 2359.4/sec |
| 200 | 1452045 | 82 | 212 | 4 | 367546 | 0.00% | 2416.9/sec |
| 500 | 1334830 | 224 | 625 | 4 | 417365 | 0.01% | 2222.5/sec |
| 1000 | 1289467 | 464 | 1039 | 4 | 597210 | 0.02% | 2144.2/sec |
八、结果
2cpu 4GB内存压测:
| 测试项 | 并发数 | 线程组增量 | 持续运行时间 | 响应时间(ms) | 成功率 | CPU使用率 | 内存使用率 |
|
| 50 | 每秒增加50个 | 10分钟 | 20 | 100% | 45%—85%之 | 75% |
| 100 | 每秒增加100个 | 10分钟 | 42 | 100% | 40%—85% | 75% | |
| 200 | 每秒增加200个 | 10分钟 | 82 | 100% | 65%—85% | 75% | |
| 500 | 每秒增加500个 | 10分钟 | 224 | 99.9999% | 63%—87% | 75% | |
| 1000 | 每秒增加1000个 | 10分钟 | 464 | 99.9998% | 45%—85% | 75% |
九、结论及建议
1.结论：
2cpu 4GB内存压测:当压测开始发现硬件CPU及内存存在不足,并发数增加到了500个,服务器的平均响应速度变得慢,并且开始有数据请求失败cpu及内存是个瓶颈。
PS：该服务器还有一些其他服务运行这占有一定的CPU及内存对数据结果是存在一定的影响的。所以此数据只能作为参考值来看。
2.建议：
依照目前服务情况达到500将是极限，建议增加CPU及内存或作负载均衡，方可维护服务的稳定，目前硬件配置为2CPU ，4GB内存。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
