在分布式开发中,我们将每一一种服务都抽取成一个独立的模块,微服务模块在真正的上线之前,甚至是上线以后,我们都要进行压力测试,才能投入正常的使用。
压力测试是为了我们的系统在当前软硬件环境下,最大的负荷量,也就是系统瓶颈。
知道了系统瓶颈,就可以通过一些负载均衡配置,避免给系统在单位时间内发送太多的请求,导致系统被压垮,以至于宕机。
同时压测也是我们优化的一个重要手段,使用压力测试,我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是:内存泄漏,并发与同步。
响应时间(Response Time: RT)
响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间。
HPS(Hits Per Second) :每秒点击次数,单位是次/秒。
TPS(Transaction per Second):系统每秒处理交易数,单位是笔/秒。
可以理解为一个事务,不仅仅是数据库的事务,例如下单需要库存、购物车、计算价格等等,全部完成,则为一个事务。
QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。
对于互联网业务中,如果某些业务有且仅有一个请求连接,那么 TPS=QPS=HPS,一般情况下用 TPS 来衡量整个业务流程,用 QPS 来衡量接口查询次数,用 HPS 来表示对服务器单击请求。
无论 TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好,根据经验,一般情况下:
最大响应时间(Max Response Time) 指用户发出请求或者指令到系统做出反应(响应)的最大时间。
最少响应时间(Mininum ResponseTime) 指用户发出请求或者指令到系统做出反应(响应)的最少时间。
90%响应时间(90% Response Time) 是指所有用户的响应时间进行排序,第 90%的响应时间。
从外部看,性能测试主要关注如下三个指标
官网下载二进制文件

windows 本身提供的端口访问机制的问题。
Windows 提供给 TCP/IP 链接的端口为 1024-5000,并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。
我们使用jmeter对接口做了压测,可以得到这个接口的一些性能报告,我们通过衡量这些性能报告,就能知道这个接口有没有符合我们的性能要求,如果不符合,我们就要对接口进行优化。
优化需要考虑多方面:
性能优化主要在应用程序方面主要是优化我们项目接口的代码编写方式和jvm的堆,可以看java虚拟机的1.1.1 堆空间内存分配(默认情况下)
jvm性能监控我们用的是jdk自带的jvisualvm(dos窗口敲jvisualvm即可启动)

休眠:调用了sleep的线程
等待:使用了wait,等待被唤醒
驻留:线程池里空闲的线程
监视:几个线程发生了锁的竞争(阻塞的线程),正在等待锁的释放