作者回复: 杨军你好,系统负载代表单位时间内正在运行或等待的进程或线程数,代表了系统的繁忙程度,CPU利用率则代表单位时间内一个线程或进程实时占用CPU的百分比。我们知道,一个进程或者线程在运行时,未必都在实时的利用CPU的。
比如,在CPU密集型的情况下,系统的负载未必会高,但CPU的利用率肯定会高,一个线程/进程一直在计算,它对CPU的实时利用率是100%,而系统负载是0.1;
又比如,而对于I/O密集型的程序来说,有可能CPU的利用率不高,但系统的负载却会非常高,这是因为I/O经常引起阻塞,这样导致很多线程/进程被处于阻塞等待状态,处于等待的线程或进程也是属于负载线程/进程的。
通过以上两个例子,不知道有没有让你分清楚两个指标的区别,有问题保持沟通。
作者回复: 遇见阳光 你好,TPS(transaction per second)是单位时间内处理事务的数量,QPS(query per second)是单位时间内请求的数量。TPS代表一个事务的处理,可以包含了多次请求。很多公司用QPS作为接口吞吐量的指标,也有很多公司使用TPS作为标准,两者都能表现出系统的吞吐量的大小,TPS的一次事务代表一次用户操作到服务器返回结果,QPS的一次请求代表一个接口的一次请求到服务器返回结果。当一次用户操作只包含一个请求接口时,TPS和QPS没有区别。当用户的一次操作包含了多个服务请求时,这个时候TPS作为这次用户操作的性能指标就更具有代表性了。
作者回复: 可以自己实现自定义异常,继承RuntimeException,然后将writableStackTrace设置为false。
以下是RuntimeException的构造函数:
protected RuntimeException(String message, Throwable cause,
boolean enableSuppression,
boolean writableStackTrace) {
super(message, cause, enableSuppression, writableStackTrace);
}
作者回复: 可以通过tcpdump抓包看看连接状态,分析是否是服务端的FIN packet没有发出去。
正常的关闭流程是:服务端在接收到客户端发送的关闭请求FIN后,会进入CLOSE_WAIT状态,同时发送ACK回去。在完成与客户端直接的通信操作之后,再向客户端发送FIN,进入LAST_ACK状态。
如果连接是CLOSE_WAIT状态,而不是LAST_ACK状态,说明还没有发FIN给Client,那么可能是在关闭连接之前还有许多数据要发送或者其他事要做,导致没有发这个FIN packet。
建议确定关闭请求的四次握手,哪个环节出了问题,再去排查业务代码,可能是由于超时或者异常导致没有正常关闭连接。
作者回复: 晚上好 QQ怪,你说的很对。我们平时在使用AB进行压测时,会有一个failed requests指标,本身接口没有异常的情况下,压测出现了异常,也是说明这个接口有性能问题。还有就是percentage of the requests served within a certain time这个指标,这个指标对金融交易系统来说是非常重要的,如果有99%的请求是1ms返回,但有1%是500ms返回,这对于某些对交易时间要求极致的金融系统来说也是性能问题。感谢你的回答,期望我的回答能让你满意!
作者回复: 如果没有生成堆栈追踪信息,不会有性能问题。一般业务异常避免生成堆栈追踪信息,我们知道这个异常是什么原因,所以直接返回字符串就好了。而系统异常,一般都会生成堆栈追踪信息,以便追踪源头,更好的排查问题。
作者回复: 你好 Phoenix,切忌在主库中操作这种报表类的导出,在写入和查询都在一个主库进行,会造成数据库性能瓶颈,严重的会导致数据库死锁。我们可以将数据库读写分离,写业务走主(写)库,导出数据可以从从(读)库导出。这种实现方式,首先能提高数据导出的性能,其次不影响写业务。
如果你们公司有大数据中心,可以考虑将需要导出的数据实时同步到大数据中心,通过实时的流计算处理生成不同需求的业务数据。
希望以上的回答能让你满意,如果有问题保持沟通!
编辑回复: 为你手动点赞👍🏻
作者回复: 你好Mr.Huang,比较常用的压力测试工具有AB,这是一个Linux系统工具,使用起来很简便,还有jmeter工具,可以在Windows环境下运行使用,个人比较习惯使用AB。
编辑回复: 坚持就会有收获,加油!
作者回复: 你好 我行我素,感谢你的回答。并发用户数代表系统同一时间处理事务的并发能力,也是体现系统性能的一个直接性能指标。当然,TPS也能间接的体现系统并发处理能力。
作者回复: 你好 Seal,你的描述很准确,QPS/TPS这两个性能指标非常相似,都是描述吞吐量的性能指标,QPS特指的一次查询请求,TPS是指每次处理事务请求,TPS包括了QPS,例如一个事务处理可能包括多个查询请求。
作者回复: 偶尔一两次异常情况是不会影响系统的性能,但在峰值出现大量请求异常,会影响到系统性能。
建议查看下是否重写了业务的异常。我们一般在定义业务异常时可以自己实现自定义异常,继承RuntimeException,然后将writableStackTrace设置为false。
以下是RuntimeException的构造函数:
protected RuntimeException(String message, Throwable cause,
boolean enableSuppression,
boolean writableStackTrace) {
super(message, cause, enableSuppression, writableStackTrace);
}
作者回复: 进程或线程,不单单指的是进程。可用使用top指令查看整体的使用率以及单个进程和单个线程的使用率。
作者回复: 建议使用jmeter或者loadrunner,可以通过录制业务流程,生成jmeter脚本。近期我会讲到测试工具的使用。
作者回复: 这位同学,你好。我们这里描述的三种吞吐量,一个是应用服务的吞吐量,然后就是磁盘和网络吞吐量。上述描述不是在强调磁盘和网络吞吐量决定了应用服务的吞吐量的必然关系。在某些情况下,磁盘的吞吐量和网络的吞吐量会影响我们应用服务的吞吐量。而在磁盘性能以及网络带宽合理的情况下,两者对应用服务吞吐量的影响是最小的。
以上我的解释希望能帮你更好的理解,有问题保持沟通。
作者回复: 这位同学,我今晚尝试模拟重现你说的问题,但是没有成功。希望你能贴出具体的配置信息,或者更详细的日志,希望我能帮你找到一些线索。
作者回复: 行者你好,你想到的很好,我们在做性能测试的时候有一个percentage of the requests served within a certain time指标,就是反应单位时间内,不同响应时间的占比率,例如50% 的响应时间是1ms以内,80%的响应时间是2ms以内,99%的响应时间是5ms以内。说明有19%是在2ms~5ms以内,如果这个范围太大,有可能存在性能问题,具体问题具体分析。
上述我说的这个参数应该就是你现在描述的性能指标,有问题保持沟通。