mirror of
https://gitee.com/shishan100/Java-Interview-Advanced
synced 2024-12-01 02:28:54 +00:00
43 lines
2.5 KiB
Markdown
43 lines
2.5 KiB
Markdown
|
|
|||
|
很常问,很多人回来跟我说,老师,我不知道我们系统每秒钟请求有多少,每天请求量有多大,我都没任何的概念,因为系统开发好直接部署,根本不管这些东西,有没有什么比较好的工具可以看到服务的访问量,qps
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
每个服务每天多少请求量,高峰期每秒钟多少请求量,你完全可以在代码里,稍微加一些metrics的代码,如果你看过很多的开源项目的话,开源的分布式系统,eureka、hadoop、spark、hbase、kafka,metrics机制
|
|||
|
|
|||
|
|
|||
|
任何一个开源系统都需要对自己运行过程中各种请求量、每秒的请求量、成功次数、失败次数,在内存里直接做一些计数,他会给你开放一些端口号,比如http端口号,你只要请求他这个端口号,他就会把这些metrics统计返回给你
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
在你负责的核心服务里,核心接口,开发一个简单的metric统计机制,AtomicLong,原子性,并发下数据统计准确,不会错误,每个接口被调用的时候,一个是可以对每个接口每分钟都做一个Metric统计
|
|||
|
|
|||
|
对每个接口每天的请求使用一个AtomicLong做一个计数,统计出来每天的请求次数
|
|||
|
|
|||
|
计算一下每个接口从请求到执行完毕,需要耗费多长时间,算一下每个接口平均的请求延时,TP99,TP95,TP90,TP50,TP99,99%的请求耗费的时间在100ms以内,但是1%的请求可能耗费的时间在100ms以上
|
|||
|
|
|||
|
**TP99 = 100ms**
|
|||
|
**TP95 = 50ms,95%的请求耗费的时间多在50ms以内,但是5%的请求耗费的时间在50ms以上**
|
|||
|
|
|||
|
平均响应延时
|
|||
|
|
|||
|
你可以计算出来这个接口平均响应延时,把每次调用的耗时跟历史总耗时加起来,除以当前的请求次数,不就是最新的接口响应平均延时
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
你完全可以通过log4j,logback,日志组件,把每分钟每个接口被访问的次数直接打印到日志文件里去,除以60,不就知道高峰期每秒钟系统被访问的次数了吗,每天每个接口访问的总次数打印到日志里去
|
|||
|
|
|||
|
|
|||
|
|
|||
|
压测工具,百度一下:java压测工具,开源的可以用的,模拟出来同时有多少用户发起多少请求,每秒发起1000请求能抗住吗?每秒钟发起2000请求能抗住吗?
|
|||
|
|
|||
|
假设你的系统每秒钟最多抗800请求,如果你的压测工具每秒发起了1000个请求,此时他会发现最多只有800个请求同时可以被处理,剩余200个请求需要进行排队被阻塞住了,告诉你,你的这个系统每秒钟最多抗800个请求
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|