测试IDServer的性能以及加锁对性能的影响

1.测试内容和目的

   目前正在基于通用框架开发IDServer（ID生成服务），第一期的基本功能已经完成，希望通过压力测试它的性能。

   同时由于IDServer使用的SnowFlake算法中的自增码，在多线程环境中有可能发生冲突，需要加锁进行保护。刚好可以借这个机会，测试下传说中的”性能杀手”--锁对性能的影响。

2.测试工具和环境

   使用webbench，在172.30.204.122机器（x86_64 CentOS 6.3)上进行测试。

   服务器的配置文件里把日志级别设成WARN，标准输出关闭。

测试代码段：

3.测试结果

Webbench -t 10 -n 分别为1000/3000/5000，每个n，测试3次，则测试得到的RPS值：

1. 上锁时的性能

2.没锁时的性能

3.性能对比

4.结果分析和思考

1. 单从RPS看，目前的IDServer应该能够满足目前的评论量（每天30~60w）和UGC内容量（每天1000以上）需要的ID数。

    但IDServer生成ID的极限量和唯一性还需要继续测试。

2. 从性能对比数据来看，对自增ID进行加锁，对性能的影响不大，在IDServer中可以使用。分析可能的原因是，是算法里在毫秒时间内自增码被多个线程同时访问的概率不大，同时目前IDServer里开启的线程数不多（使用的是cpu的核数），切换的开销较小（加锁造成性能消耗的主要原因）。

3. 在实际的测试中，发现一个现象，在-c 5000的时候，实际的RPS变化比较大，从23000~43000值都有，而且在区间两端分布的概率很大！

   虽然通过多次测试，能得到一个平均值，但是对结果的影响产生了疑问？具体原因也不太清楚 (希望牛人们帮忙分析)

5.鸣谢

IDServer里加锁采用的是互斥锁，后来萌萌建议使用自旋锁，他的建议：

“互斥锁，如果线程获取的锁已经被加锁的话，当前线程就会被阻塞，会发生线程的上下文切换；自旋锁如果发现加锁的话，会循环等待，不会让出cpu，也就不会有线程的上下文切换；如果线程数量比较多的时候，上下文切换的成本比较高。但是，从自旋锁的特性也知道，自旋锁只适应于这种临界区代码执行时间比较短的场景，比如代码里面自增id的部分。”

之前由于偷懒，现在应要求又把两种锁对比的测试数据补上。

自旋锁：

对比数据：（注意-c 5000时，测试的数据有异常）

通过对比发现确实两种锁，在这样的应用场景下，对性能的影响差别不大。

分析：当然不是萌萌的建议的有误，而是在IDServer的一个业务中，锁本来对性能的影响比较小，所以不管公锁母锁都一样