【问题标题】:Microbenchmarking with Big Data使用大数据进行微基准测试
【发布时间】:2012-10-10 17:27:26
【问题描述】:

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

我需要进行基准测试的缓存大约是 Map 接口的十几个实现。这些缓存旨在与给定的访问模式(从上面的算法中查询密钥的顺序)很好地配合使用。然而,在一个“小”问题的给定运行中,有几千亿个查询。我需要运行几乎所有这些,才能对基准测试的结果充满信心。

我在将数据加载到内存时遇到了概念性问题。可以创建一个查询日志,它只是在一次算法运行中查询的所有键(它们是 10 个字符的字符串标识符)的磁盘有序列表。这个文件是巨大的。我的另一个想法是将日志分成 1-5 百万个查询的块,并以下列方式进行基准测试:

  1. 加载 1-5 百万个密钥
  2. 将开始时间设置为当前时间
  3. 按顺序查询
  4. 记录经过的时间(当前时间 - 开始时间)

我不确定这会对缓存产生什么影响。我怎样才能进行热身期?加载文件可能会清除 L1 或 L2 缓存中最后一个块的所有数据。此外,维护一个 1-5 百万元素的字符串数组有什么影响(甚至迭代它会扭曲结果)?

请记住,访问模式很重要!例如,有一些哈希表具有移动到前端启发式,它重新排序表的内部结构。多次运行单个块或无序运行块将是不正确。这使得预热 CPU 缓存和 HotSpot 变得更加困难(我还可以保留一个用于预热但不用于计时的辅助虚拟缓存)。

对于拥有庞大数据集的微基准测试有哪些好的做法?

【问题讨论】:

  • 不是“微基准”。这是一个“宏观基准”。
  • 但它是对单一操作进行基准测试 - 哈希表查找。
  • 如果你测量毫秒,不要使用System.currentTimeMillis,使用System.nanoTime()System.currentTimeMillis vs System.nanoTime
  • 重要的是让它在适当的硬件上变得现实。如果您使用较小的数据集,它将比加载完整的数据集执行得更好。您应该决定数据集应该有多大,并在可以支持该大小的机器上运行测试。如果您没有这么大的机器,您应该购买一台或修改您对所需设备的估计。在更大的机器上运行一个小数据集并估计它在更大的数据集上的运行速度主要是猜测工作。
  • 我假设您不是在谈论 Hashtable,因为它不能很好地扩展。我会酌情使用 HashMap 或 ConcurrentHashMap。

标签: java hashtable benchmarking


【解决方案1】:

如果我正确理解问题,如何在一台机器上加载查询日志,如果您没有足够的内存,可能以块的形式加载,然后通过专用网络(交叉电缆)将其流式传输到运行基准测试的机器上,可能),所以您在被测系统和测试代码/数据之间的干扰最小......?

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

更新:回复:批处理和计时 - 在实践中,您可能最终会使用某种形式的细粒度批处理,至少可以有效地通过网络获取数据。如果您的数据属于自然的大型“组”或阶段,那么我会单独对它们进行计时以检查异常情况,但最强烈地依赖于整体时间安排。我看不出对数千个小批量进行计时有多大好处(鉴于您正在运行数百万个)。

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

【讨论】:

  • 如果您使用网络,您是在密钥进入时逐个执行密钥查找,还是应该以 10,000 或 1,000,000 次查找为一组进行批量查找?在任何一种情况下,您会安排多少时间(所有内容或查找组)?
  • 作为参考,读取文件大约需要运行测试(读取文件、创建测试数组、执行所有查找)所需的全部时间的 80-90%。
  • 在这种情况下,听起来值得投资足够的 RAM 来加载数据集一次,然后将其提供给多个候选者。
  • 我的桌面上有 16GB 的 RAM,但我担心的是加载文件的速度(以及它具有的任何缓存效果)。
猜你喜欢
  • 1970-01-01
  • 2017-07-07
  • 1970-01-01
  • 2018-01-22
  • 2018-09-12
  • 1970-01-01
  • 2012-01-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多