tprofiler对性能的影响测试结果
- Dominant language
- Java
- Stars
- 2.4k
- Forks
- 906
- PR merge metrics
- No merged PRs in 30d
Description
配置:
startProfTime = 17:28:00
endProfTime = 20:00:00
eachProfUseTime = 5
eachProfIntervalTime = 50
samplerIntervalTime = 20
port = 50000
debugMode = false
needNanoTime = false
ignoreGetSetMethod = true
#
同一个接口,相同参数,没有cache 压测结果:
**结论:qps几乎没什么影响, 这是为什么?**
不使用tprofiler的压测结果:
summary + 80918 in 7.3s = 11093.8/s Avg: 14 Min: 0 Max: 122 Err: 0 (0.00%) Active: 200 Started: 200 Finished: 0
summary + 355915 in 30s = 11863.8/s Avg: 16 Min: 11 Max: 30 Err: 0 (0.00%) Active: 200 Started: 200 Finished: 0
summary = 436833 in 37.3s = 11712.9/s Avg: 16 Min: 0 Max: 122 Err: 0 (0.00%)
使用tprofiler的压测结果:
summary + 308453 in 27s = 11421.6/s Avg: 16 Min: 1 Max: 205 Err: 0 (0.00%) Active: 200 Started: 200 Finished: 0
summary = 308454 in 27.2s = 11352.7/s Avg: 16 Min: 1 Max: 205 Err: 0 (0.00%)
summary + 359548 in 30s = 11984.9/s Avg: 16 Min: 9 Max: 57 Err: 0 (0.00%) Active: 200 Started: 200 Finished: 0
Contributor guide
No contributing guide indexed for this repository
Research direction
The issue names no source files, tests, or entry points. Start by reproducing the paired load-test runs with and without TProfiler using the listed configuration, then trace the profiler startup and sampling path. Done means documenting why the measured QPS is nearly unchanged and identifying any confirmed instrumentation or benchmark limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100