扫码阅读
手机扫码阅读

随机方法性能差异

80 2024-04-13

在之前的文章中我分享了三种从一个数组中随机取一个值的方法,分别是:使用随机数、使用int递增,使用atomicinteger递增。其中后两者都是循序取,并非真的随机。从上次的测试结果中,随机数方案相对后两者性能差异比较大。但是当时多线程的测试都是在达到了CPU性能瓶颈的情况下测得,旧闻如下:性能测试中的随机数性能问题探索

最近又遇到相同的问题,为了更加准确反映三个方案的性能差异,我打算在压力相对偏低的情况下重新测试。毕竟之前测试的都是几百万的QPS,日常使用中根本不会用的这么高的场景。

用例设计

使用固定QPS模型进行测试,这样可以一次测试中获取多组测试数据,然后每次执行增加10ms的延迟,模拟接口响应耗时。这次没有覆盖从数组中取值,因为对于所有的实现方案,这个步骤是相同的,只是获取一个数组的索引。

用例如下:

import com.funtester.frame.SourceCode import com.funtester.frame.execute.FunQpsConcurrent import groovy.util.logging.Log4j2 import java.util.concurrent.atomic.AtomicInteger @Log4j2 class Ts extends SourceCode { static void main(String[] args) { def total = 1000_0000 def index = new AtomicInteger() int i = 0 def test = {
            i++ % total //            index.getAndIncrement() % total getRandomInt(total)
            sleep(0.01)
        } new FunQpsConcurrent(test, "测试随机性能").start()
    }
} 

测试结果

本次数据统计使用Intellij自带的profiler获取,之前常用的jconsole和jvisualvm突然不好用,连接不上JVM了。下面分享一下测试结果

方案 TPS(万) CPU(百分比)
random 1 13
int 1 15
atomic 1 12
random 2 26
int 2 30
atomic 2 24
random 3 38
int 3 46
atomic 3 38
random 4 51
int 4 60
atomic 4 51
random 5 64
int 5 75
atomic 5 64

从以上数据看出,随机数的CPU消耗量是非常大的,这里我没有把内存列出来,因为前两项测试中并没有看到内存大较大差异。但是在执行atomic方案的方案的时候内存升高较多。随机数和int方案堆内存使用最大量约50M,而atomic使用量最大130M,不过这个增量可以接受的。

除了以上,我还发现一个有趣的现象,如果我先测1万,后测试5万。或者我先测5万,然后降低到1万。两个差距还是挺大的。下面分享一下数据,按照测试时间记录数据。

方案 TPS(万) CPU(百分比)
atomic 0.5 1
atomic 1 3
atomic 2 10
atomic 3 24
atomic 4 40
atomic 5 64
atomic 4 50
atomic 3 38
atomic 2 26
atomic 1 12
atomic 0.5 6

看了监控,怀疑是后面活跃线程持续增长导致的,那么是否可以认为,这里CPU使用率差异都是在线程的切换导致的,我现在倾向于是的。后面有机会我会对线程数这个参数进行对比测试,继续优化FunTester框架。

原文链接: http://mp.weixin.qq.com/s?__biz=MzU4MTE2NDEyMQ==&mid=2247498580&idx=1&sn=13d37be48b70afd9e29164a3eda15228&chksm=fd497662ca3eff748c4dda4e9f834bd4eebf383b0ef9c7be60000de2d958e417d8dd6fd3fcaa#rd