【IT168 技术】前面两篇文章主要对HandlerSocket从整体上做一些介绍，本文从性能及其性能优化方面来做一些介绍。
系列文章：
一、HandlerSocket性能
HandlerSocket作者测试HandlerSocket在查询情况下QPS为75K，Memcached为40K，MySQL为10K。但是需要注意到它的测试场景，一般的应用是很难有这样的场景的，所以说一般应用是很难达到7.5倍于MySQL的情况，但是性能的大幅度提高是不容置疑的。作者的测试场景如下：
1. 关闭MySQL的query cache：也就是MySQL的每次操作都需要执行sql解析等那一系列操作。
2. CPU Bound而非I/O Bound：InnoDB Buffer Pool设置为比较大，命中率接近100%。
所以，应该更客观的来看待测试数据。对于CPU Bound而非I/O Bound类型的应用，在InnoDB_Buffer_Pool接近100%命中率的时候，HandlerSocket可以将查询性能提高7.5倍。这一点其实不难理解，因为HandlerSocket主要性能优化点在于节省了SQL层的开销，SQL层的开销主要是CPU的开销。而如果对于一个I/O Bound的应用来说，HandlerSocket的查询性能可能就达不到7.5倍了，可能距离7.5倍有比较大的差距，所以，对于HandlerSocket的应用来说，应该尽量提高InnoDB_Buffer_Pool的大小，多多益善。
我也做过一些基准测试，基本上在插入的情况下，HandlerSocket的性能能达到同等环境的MySQL的3-5倍，数据量越大时候越明显，特别是达到5000万以后。在查询情况下，HandlerSocket是同等环境下MySQL的1.5-2倍，这跟作者的测试的7.5倍有比较大的出入，这也是上面我特别提到的，作者的测试数据是在Innodb_Buffer_Pool足够大并且命中率很高的情况，由于我做基准测试的机器条件有限，没有足够大的Buffer Pool，命中率不是很高，所以，I/O开销不小，这也验证了上面提到的，对于I/O Bound的场景，性能的提升不会特别的明显，所以应该尽量增大InnoDB_Buffer_Pool的大小，尽量接近于数据的大小。而且我在测试的时候，没有关闭Query Cache，所以对于MySQL的测试场景来说，能重用到执行计划和Cache数据等。
上面说到了，HandlerSocket具有不少的优点，性能也有很大的提升，但是也需要理性的来看待，有一些需要特别注意的事项，在做决策的时候，应该整体上的考虑，我这里简单的总结一下。
1. 应该尽量达到CPU-Bound场景，而非IO-Bound，这样才能更好的发挥出HandlerSocket的优势。具体做法是增大内存，尽量提高InnoDB_Buffer_Pool大小。
2. 由于采用合并操作，响应时间会有不同程度的增加，应该考虑好是否满足你的应用场景。可以继续关注后续版本优化策略，比如可能有些朋友会想要这样的：读取的时候不是合并操作，但是写入是合并操作，当然这样的情况读取的总体性能会有不同程度降低，不过一切不就是在权衡嘛?还是看具体应用场景。
