Java 大数据微基准

我目前正在做我的论文项目，设计一个与最短路径图算法一起使用的缓存实现。图形算法与运行时相当不一致，因此对整个算法进行基准测试太麻烦。我必须只专注于对缓存进行基准测试

我需要基准测试的缓存大约有十几个

Map

接口的实现。这些缓存被设计为与给定的访问模式（从上述算法中查询密钥的顺序）配合使用。然而，在一个“小”问题的给定运行中，有数千亿个查询。我需要运行几乎所有的测试，才能对基准测试的结果充满信心

我在将数据加载到内存的概念上有问题。可以创建一个查询日志，它只是一个磁盘上的有序列表，其中列出了在一次算法运行中查询到的所有键（它们是10个字符串标识符）。这个文件很大。我的另一个想法是将日志分成100-500万个查询块，并以以下方式进行基准测试：

加载1-5百万个密钥

将开始时间设置为当前时间

按顺序查询它们

记录经过的时间（当前时间-开始时间）

我不确定这会对缓存产生什么影响。我如何进行热身？加载该文件可能会清除最后一个块的L1或L2缓存中的所有数据。另外，维护一个1-5百万元素的字符串数组有什么影响（甚至迭代它也会使结果倾斜）

请记住，访问模式非常重要！例如，有些哈希表使用move-to-front启发式方法，对表的内部结构进行重新排序。多次运行单个块或无序运行块是不正确的。这使得预热CPU缓存和热点变得更加困难（我还可以保留一个用于预热但不用于计时的辅助虚拟缓存）

---

对于具有巨大数据集的微基准，有哪些良好实践

如果我正确理解了这个问题，那么在一台机器上加载查询日志如何？如果内存不足，可以分块加载，然后通过专用网络（可能是交叉电缆）将其流式传输到运行基准测试的机器上，这样，被测系统之间的干扰最小，测试代码/数据

无论您使用什么解决方案，您都应该尝试多次运行，以便评估可重复性-如果您没有获得合理的可重复性，那么您至少可以检测到您的解决方案不合适

更新：re：批处理和计时-在实践中，您可能会得到某种形式的细粒度批处理，至少可以通过网络高效地获取数据。如果您的数据属于自然大的“组”或阶段，那么我会对这些数据进行单独计时，以检查异常情况，但最依赖的是总体计时。我看不出对数千个小批量进行计时有多大好处（考虑到您正在运行数百万个）

---

即使您在一台具有大量RAM的机器上运行所有内容，也可能值得在一个JVM中加载数据，在另一个JVM上加载正在测试的代码，这样缓存JVM上的垃圾收集就不会（直接）受到保存查询日志所需的大堆的影响

这不是一个“微基准”。它是一个“宏基准”。但它是对单个操作的基准测试——一个哈希表查找。如果你测量毫秒，不要使用

System.currentTimeMillis

，使用

System.nanoTime（）

：重要的是在适当的硬件上实现它。如果使用较小的数据集，它的性能将优于加载完整的数据集。您应该决定数据集的大小，并在支持该大小的机器上运行测试。如果你没有那么大的机器，你要么买一台，要么修改你对所需的估计。运行一个小数据集并估计它在一台更大的机器上的更大数据集上的速度主要是猜测工作。我假设您不是在谈论哈希表，因为它的伸缩性不好。我会根据需要使用HashMap或ConcurrentHashMap。如果你使用网络，你是在密钥进入时一个接一个地执行密钥查找，还是应该以10000或1000000次查找为一组进行批处理？在这两种情况下，您将对（所有内容或查找组）进行多少计时？作为参考，读取文件大约需要运行测试所需时间的80-90%（读取文件、创建测试数组、执行所有查找）。在这种情况下，听起来值得投资足够的RAM来加载数据集一次，我的桌面上有16GB的内存，但我担心的是加载文件的速度（以及缓存的效果）。