《用java并发测试tokyo cabinet的性能[重大更正篇]》的评论

java List转byte[]的方法 | 我是陈科学院-about php and java|php与java科学院

java List转byte[]的方法 | 我是陈科学院-about php and java|php与java科学院 — Tue, 08 Dec 2009 03:47:22 +0000

[...] 从后面一个例子看到的object在toString的时候，对象只是一个串了，要想再恢复成object不可能了。54chen曾想把list.toString.getBytes，被证明是不靠谱的做法。 [...]

[科学院手记]人人网新鲜事分享现场转播 | 我是陈科学院-about php and java|php与java科学院 — Wed, 02 Dec 2009 09:44:28 +0000

[...] TC的测试结果： [...]

Wed, 11 Nov 2009 10:20:01 +0000

[...] 用java并发测试tokyo cabinet的性能[重大更正篇] [...]

cc0cc — Tue, 03 Nov 2009 08:11:20 +0000

发现大于10后并发的增加对速度影响不大了
bnum mmap size之间是什么关系呢，我这里用到的是table表，好像性能不错的是b+
：）

agentzh — Tue, 03 Nov 2009 07:30:56 +0000

一般地，bnum 应当设置为总数据量的 2 倍以上，这不同于把 mmap size 调大一些就足够了。在这里便是用完你磁盘的所需的 key 的数量的 2 倍以上。

因为这里咱们本质上使用的是 hash 数据结构，自然要把 bucket 的数目设置得合理一些。呵呵。

另外，10 并发感觉小了些，可以试试更高一些的并发，比如 C10K？呵呵。

cc0cc — Mon, 02 Nov 2009 10:01:58 +0000

高并发的一直写入下，tc调整大了bnum能抗一阵速度很快，但mysql可以一直抗到硬盘满了，速度一直中等。
：P

agentzh — Mon, 02 Nov 2009 02:09:41 +0000

没有单机磁盘可以做到“没有写满的一天”，呵呵。

cc0cc — Mon, 02 Nov 2009 01:57:32 +0000

看上去调大这个值持续写入的话，还是会有写满的一天，那还是不可取的，我都转向了用mysql模拟key-value，毕竟是更熟悉的东西

agentzh — Mon, 02 Nov 2009 01:24:34 +0000

貌似你在使用 TC 的 hash 的时候，没有调整 bnum 的值？我没记错的话，默认仅 30 万个桶，这意味着一旦超过 30 万数据，则会大量出现 key conflict，性能急转直下，也便不足为奇了，呵呵。另外，还有其他的 TC 优化选项，默认的都很保守