分析 mnesia 索引慢的问题，结果出乎意料.

分析 mnesia 索引慢的问题，结果出乎意料.

因为 ejabberd 设计思路对 mnesia 做缓存情有独钟。

排除 cowboy 系统本身性能问题之后决定分析代码。

前段时间对Cloud做压力测试意外发现，当测试将要结束时，从出现socket断开开始系统变得非常缓慢。甚至一个 http 请求相应也得花上1分多钟，甚至更长，这显然问题非常严重。对缓存性能之前做过测试，所以分析问题时直接跳过了。其实问题就是出现在缓存上。最终定位，当缓存数据达到5W条记录后，性能急剧下降，特别是删除数据和同样重复写入。每秒也就只能处理2k~3k 的样子。这结果令人沮丧，这样的性能怎能适合做缓存。

深深的回忆，之前测试和现在区别就是多了 index。难道 index 对性能影响如此之大。查了一下手册，手册上是这样说的：

“ Indices do not come free, they occupy space which is proportional to the size of the table. They also cause insertions into the table to execute slightly slower.

”

好吧，我相信了是索引造成的。

开始解决索引问题。差了好多资料有说慢的，可是没有找到与我一样的描述。因为我没有用 disc_copes。我全部用的 ram_copies. 群里咨询也没有看到很好的反馈，也得到了些帮助，在此感谢。

头脑中产生了两种想法。一是用 多表+transaction，二是纯碎多表+no transaction.

赶紧写代码测试，transaction 在意料之中慢的很，还抛出一些错误。no transaction 不但没有预期的快，还发写数据和删除现数据不完整。

分析了一下数据存储形式，list 过程会导致性能降低（dict数据结构从思绪中闪过）。为了解决多表no transaction数据不完整问题，把表的默认类型从 set 改为 bag.这样数据能准确的插入和删除，不会出现覆盖问题。测试没问题。速度有所降低，但还能接受。数据不完整问题也解决了。想到此方法是否可以用到transaction 上面。

 

开始了 transaction+bag 测试。性能降低到同样让人绝望。想到用 transaction+bag +单表测试。结果发现 速度很快超出预期。一个个表添加依然很快。最后定为到 ws_type 表上面去了。这样一下子明白了。立刻切回 no transaction+index 去掉 type索引读写删速度都非常之快50W条数据都在毫秒内完成，第一次写总共花费 14121 ms，第二次重复写 21423 ms,删除数据 14777 ms，心情一下子晴朗了。接下来需要解决的就是 type 问题了。

无论用 index 还是 bag 类型，甚至分表K<->ValueList当 ValueList 超过2W 速度照样拖慢。这才是拖慢读写的本质。

<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->

Type 当前只有两种类型 D和C。当有5W 条数据后。index、bag、另一张表（与 index 类似）速度通通慢的不行。