对测试IDServer加锁性能后，收到建议反馈后的思考总结

作为公司的新人小菜鸟，在对《IDServer性能以及加锁的影响》进行测试，并抛出发现的问题后，收到了很多大牛的热情反馈和宝贵建议，有些建议真是一针见血，直接指出了测试中的一些缺陷，有些建议很好地指出了IDServer可以改进的方向。在此本人备受鼓舞，同时也感受到学海无涯！

现在先把一些建议和反馈，以及自己思考后对测试的改进在这展示，欢迎大家继续吐槽！

1.上次测试时，webbench和IDserver服务器是在同一个机器上，这样会导致一些问题，比如测试高并发时两者都很消耗机器的性能，这样可能会相互影响。（webbench -c 5000测试时，IDServer出现的RPS值异常分布的现象，就很有可能是因为这造成的。同时5000个进程太多了，这么多进程实际上对服务器本身也会有很大影响，因为进程间的切换对机器来说是一个很大的性能消耗）

2. 测试是否加锁对性能的影响，以及对比互斥锁和自旋锁的性能时，线程的个数是一个非常重要的参数。经大牛提醒才发现，之前的测试保持的是固定的线程数，这样即使再多的请求也还是那几个线程在执行，导致加锁的次数也不会有太多变化。所以，测试时应该加入线程个数的变化，这样才更准确，更有针对性。

改进后的测试方法：

IDServer还是部署在122机器（8核）上， 但webbench用的是93机器上的，线程数从1个开始，逐渐增加，观察变化。

新的测试数据：

1. Webbench -t 10 -c 1000

2. Webbench -t 10 -c 3000

结果分析和思考：

1.通过测试结果发现，从单线程到多线程变化时，IDServer的性能成倍增加，但随着线程数增加到一定值时，IDServer的性能保持平稳，此时线程数对性能的影响很小，可能是因为IDServer的逻辑基本是一个内存级的算法处理，并没有大量的耗时操作，所以多线程在这里表现出来的作用有限，后期要是
存在更多耗时操作时，多线程的优势应该能更大发挥出来。

2.测试数据表明实际上加锁前后RPS相差很小（几十左右，而且这还不能确定就是锁造成的）。分析可能是由于目前的IDServer功能比较单一，线程间对加锁的临界变量竞争不是太激烈，因此感觉在这样的场景中测试加锁对性能的影响，可能意义就不是太大。  但关于锁对性能的影响，以及何种场景下使用什么类型的锁，确实是一个很值得思考的问题！

后面本人还需要对IDServer生成算法的性能和唯一性的验证设计测试方案，到时候可以尝试爱思同学建议的原子模式操作__sync_lock_test_and_set（我已经google过了）。大家有空也可以看看IDServer使用的《基于业务对twitter的snowflake算法的改进》，给一些相关的测试建议！

p.s. 最后附上所有的测试数据，希望大家多提意见，有兴趣的话可以一起测试讨论！