写给《数据库引擎 CoolHash 性能测试报告》
程序员文章站
2022-05-06 13:00:48
...
首先第一眼印象，单机使用磁盘IO的话能支持100w qps。我只能说这是神一样的开源了。
首先来看一个概念IOPS，每秒的IO次数，内存大概是1000w，SSD盘 35000，sas盘180，stat盘90
这些数据我摘抄自《大规模分布式存储系统》，180的IOPS如何能支持100w的qps，还有CoolHash如果在一台机器上开启多个工人是并发随机IO，还是工人只负责写入内存，再用另外的线程负责将所有数据写磁盘，这样是顺序IO，大部分KV存储都是这样搞的，包括leveldb和beansdb。如果说180的IOPS能支撑100wqps，那我只能说Coolhash将sas演绎的太神奇了，CoolHash是神一样的开源产品了。
那先来看看这个http://xiaoz5919.iteye.com/blog/2072209，这这是简单的100并发100w请求，就抛出了异常，你benchmark都没有测试用例建议把测试用例和过程贴出而不是redis相比。
page cache我想大家都很熟悉吧linux的write是buffered write，首先写到page cache中，然后再后台进程刷到磁盘，写入成功了并不会将该page删除，以便以后提升read的性能，直到内存紧张才做LRU淘汰，这么看来内存充足的情况下，write和read都是在内存中完成的，而不走磁盘IO。rocksdb的benchmark提到了，如果测试的数据量规模大小小于内存，那全部的读写都在pagecache中就完成了，而不走真正的磁盘IO，你用小内存试试，或者把测试的datasize调大，rocksdb的作者说最好用5倍于内存的数量。
使用datasize 只有几个bytes的测试几乎没有太大的意义
首先来看一个概念IOPS，每秒的IO次数，内存大概是1000w，SSD盘 35000，sas盘180，stat盘90
这些数据我摘抄自《大规模分布式存储系统》，180的IOPS如何能支持100w的qps，还有CoolHash如果在一台机器上开启多个工人是并发随机IO，还是工人只负责写入内存，再用另外的线程负责将所有数据写磁盘，这样是顺序IO，大部分KV存储都是这样搞的，包括leveldb和beansdb。如果说180的IOPS能支撑100wqps，那我只能说Coolhash将sas演绎的太神奇了，CoolHash是神一样的开源产品了。
那先来看看这个http://xiaoz5919.iteye.com/blog/2072209，这这是简单的100并发100w请求，就抛出了异常，你benchmark都没有测试用例建议把测试用例和过程贴出而不是redis相比。
page cache我想大家都很熟悉吧linux的write是buffered write，首先写到page cache中，然后再后台进程刷到磁盘，写入成功了并不会将该page删除，以便以后提升read的性能，直到内存紧张才做LRU淘汰，这么看来内存充足的情况下，write和read都是在内存中完成的，而不走磁盘IO。rocksdb的benchmark提到了，如果测试的数据量规模大小小于内存，那全部的读写都在pagecache中就完成了，而不走真正的磁盘IO，你用小内存试试，或者把测试的datasize调大，rocksdb的作者说最好用5倍于内存的数量。
使用datasize 只有几个bytes的测试几乎没有太大的意义