分析 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 类似）速度通通慢的不行。