纪事本 乱码
总览
Yahoo Cloud Service Benchmark是一种相当广泛使用的基准测试工具,用于测试大量密钥(例如1亿个)和少量客户端(即由一台计算机提供服务)的密钥值存储。
在本文中,我将研究如何使用Chronicle Map在具有128 GB内存,双Intel E5-2650 v2 @ 2.60GHz和六台Samsung 840 EVO SSD的单 台计算机上使用Chronicle Map进行1亿* 1 KB键/值的测试。
1 KB值由100个字节的字符串的十个字段组成。 对于更好的解决方案,原始数将是一个更好的选择。 尽管SSD有所帮助,但峰值传输速率为700 MB / s,可以由两个SATA SSD驱动器支持。
这些基准是在报告撰写时使用最新版本的Chronicle Map 2.0.5a-SNAPSHOT进行的。
微秒世界
在阅读有关键值存储的基准时,令我感到困惑的是,它们以性能真的很重要为前提。 恕我直言,大约90%的时间里,性能不是最重要的功能,只要您有足够的性能即可。
然后,这些基准测试报告继续以毫秒(而不是微秒)报告时间,并且以数万而不是数十万或数百万的吞吐量进行报告。 如果性能确实如此重要,那么他们将围绕性能来构建产品,而不是出于性能原因 ,而不是他们支持的有用功能 (例如多键事务性,仲裁更新和Chronicle Map不支持的其他功能)。
那么,为性能而构建的密钥库在YCSB中的外观如何?
吞吐量措施
“ 50/50”测试50%随机读取和50%随机写入,“ 95/5”测试95%读取到5%写入。 预计写操作会更昂贵,读操作的百分比越高,吞吐量就越高。
线程数 | 50/50读取/更新 | 95/5读取/更新 |
---|---|---|
1个 | 122 K /秒 | 245 K /秒 |
2 | 235 K /秒 | 414 K /秒 |
4 | 339 K /秒 | 750 K /秒 |
8 | 646 K /秒 | 1.295 M /秒 |
15 | 819 K /秒 | 1.452 M /秒 |
30 | 900 K /秒 | 1.641 M /秒 |
延迟时间
以下等待时间以微秒为单位,而不是毫秒。
线程:8 | 50/50读取 | 95/5阅读 | 50/50更新 | 95/5更新 |
---|---|---|---|---|
平均 | 5微秒 | 3.9微秒 | 15.9微秒 | 11.3微秒 |
第95名 | 12微秒 | 8微秒 | 31微秒 | 19微秒 |
第99名 | 19微秒 | 14微秒 | 42微秒 | 27微秒 |
最坏的 | 67毫秒 | 70毫秒 | 67毫秒 | 70毫秒 |
注意:基准测试并非旨在免费提供GC,并会产生一些垃圾。 这不是特别高,根据飞行模拟器,基准本身仅使用大约1/4的CPU,但是确实会影响最严重的延迟。
结论
确保键值存储具有所需的功能,但是如果性能至关重要,则寻找针对性能而设计的解决方案,因为它可能比全功能产品快100倍。
其他高性能示例
有待改进
脚注
翻译自: https://www.javacodegeeks.com/2014/10/chronicle-map-and-yahoo-cloud-service-benchmark.html
纪事本 乱码