程序员-小枫的博客

多线程多线程处理用例参数和执行用例场景下，线程池的引入。这个首先解决了多用例运行的耗时太多的问题，其次也解决了每次处理任务新建线程对于性能的消耗。具体的方案就是新建一个全局的线程池，然后把所有多线程任务包装成一个线程对象，通过将任务丢到线程池中，然后通过CountDownLatch这个类实现等待执行结束，然后进行下一步操作。具体可参考：-CountDownLatch类在性能测试中应用。核心代码如下：线程池package com.okay.family.common.threadpoo.

JMeter吞吐量可能是个假数据，因为它计算的是本机而不是服务端。我自己并不用JMeter进行压测，故事的缘起是因为看到了同事适用JMeter进行测试的测试报告，偶然间发现一个问题，JMeter报告中的吞吐量误差较大。结果如图：按照经典理论模型计算吞吐量TPS或者QPS应该是等于并发线程数除以平均响应时间：tps =Thread / AVG(t)或者tps = COUNT(request) / T大家看第一个案例：平均响应时间593ms，100并发，计算得到的吞吐量为：168...

利用微基准测试修正压测结果前段时间做了一次参数需要签名的接口性能测试，有文为证：线程安全类在性能测试中应用。在处理测试结果时候遇到一个问题：因为本机签名耗时较多，10ms级别，并发情况能达到100ms级别。所以进行数据校验尤为重要。在两次请求间歇，本地只是做了测试结果的收集，测试数据的生成和签名，其中签名是最耗时的。这个时候在收集完测试数据之后，就需要进行一轮甚至几轮的微基准测试。微基准测试用来测量微小代码单元的性能，包括调用同步方法的用时与非同步方法的用时比较，创建线程的代价与使用线程池的代价

系统重构有一段时间了，也陆陆续续的做了数据迁移，业务迁移，作为整个系统的底层服务以及未来整个部门的中台系统，服务的可用性，稳定性以及性能都至关重要，因此最近在大促之前做了一次核心服务的压测。当然压测生产前必须有一个调试的过程，所以会在测试环境进行压测调试，下面就是对这次压测调试的一个分析和总结。由于个人对性能调优也是新手，经验不到，所以如果有不当之处希望有网友指出，不胜感激。问题发现首先是先对系统做个压测，压出系统的瓶颈。经过摸索，使用Jmeter工具完成了初步压测工作，并得出了以下的结论：

压力测试  压力测试分两种场景：一种是单场景，压一个接口的；第二种是混合场景，多个有关联的接口。压测时间，一般场景都运行10-15分钟。如果是疲劳测试，可以压一天或一周，根据实际情况来定。压测任务需求的确认压测前要明确压测功能和压测指标，一般需要确定的几个问题：固定接口参数进行压测还是进行接口参数随机化压测？ 要求支持多少并发数？ TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？ 压服务器名称还是压服务器IP，一般都是压测指定的服务器压测设置线程数：并发数量，能跑多少量。

 jmeter是apache公司基于java开发的一款开源压力测试工具，体积小，功能全，使用方便，是一个比较轻量级的测试工具，使用起来非常简单。因为jmeter是java开发的，所以运行的时候必须先要安装jdk才可以。jmeter是免安装的，拿到安装包之后直接解压就可以使用，同时它在linux/windows/macos上都可以使用。   jmeter可以做接口测试和压力测试。其中接口测试的简单操作包括做http脚本（发get/post请求、加cookie、加header、加权限认证、上传文件）、做webs