HandlerSocket的性能测试

HandlerSocket Oprofile测试报告

(MySQL通过SQL执行K/V查询的Oprofile信息)

MySQL执行SQL语句，首先要经过SQL解析阶段，调用MYSQLparse() 和MYSQLlex() 进行语法和词法解析；然后进入查询优化阶段，调用make_join_statistics() 和JOIN::optimize() 获得统计信息和生成执行计划，可以清洗第发现，主要耗资源的是SQL解析和优化层，而不是InnoDB存储层，row_search_for_mysql只消耗了很少的时间。

因此我们对比Memcached/NoSQL，知道MySQL除了数据操作，还要很多额外的步骤需要完成：
1  Parsing SQL statements【解析SQL】
2  Opening, locking tables【打开并锁定表】
3  Making SQL execution plans SQL【解析SQL并生成执行计划】
4  Unlocking, closing tables【解锁并关闭表】
另外，MySQL 还必须要做大量的并发控制，比如在发送/接收网络数据包的时候，fcntl() 就要被调用很多次；Global mutexes比如LOCK_open，LOCK_thread_count也被频繁地取得/释放。所以在Oprofile的输出中，排在第二位的是my_pthread_fastmutex_lock()。并且Mutex的竞争带来的上下文切换，导致%system占用CPU使用比例相当高（>20%）。

其实， MySQL 开发团队和外围的开发团体早已意识到大量并发控制对性能的影响，MySQL 5.5中已经解决了一些问题，Percona也对Mutex做了一些拆分处理，未来的MySQL版本中，也应该会越来越好。

在完全内存操作的情况时，CPU的效率非常重要。如果只有一小部分数据进入内存，那么SQL语句带来的消耗可以忽略不计。很简单，因为机械磁盘IO操作的时间消耗远比CPU解析SQL语句的时间消耗多，这种情况下，就不需要过分考虑SQL语句所带来的消耗。但是对于SSD盘，尤其是PCI-E SSD盘，响应时间在微秒级（Fusion I/O为30us左右），就必须考虑SQL带来的消耗了。
在大多数的MySQL 服务器中，大部分的热点数据都缓存在内存中，因而访问变得只受CPU的限制。Profiling 的结果就类似上所述的情况：SQL 层消耗了大量的资源。假设需要做大量的PK查询（例如：SELECT x FROM t WHERE id=?）或者是做LIMIT的范围查询，即使有70-80%都是在同一张表中做PK查询（仅仅只是查询条件中给定的值不同，即value不同而已）， MySQL 还是每次需要去做 parse/open/lock/unlock/close， 这对我们来说是非常影响效率的事情。

 (MySQL通过HandlerSocket执行K/V查询的Oprofile信息)

HandlerSocket性能测试报告：

【测试主机】
机型：R510
CPU：Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
内存：4G*6
磁盘：146G*2(OS) + 300G*12 RAID10(data)
1)         完全随机测试

测试场景描述：

²  单实例MySQL 5.1.48 InnoDB Plugin

²  测试SQL：INSERT INTO table (key, value) VALUES(#key#, #value#) / SELECT value FROM table WHERE key=#key#

²  HS API：execute_single

2)         重复获取同一条数据

测试场景描述：
1 单实例Percona 5.1.57-12.8 XtraDB
2  测试SQL：SELECT value FROM table WHERE key=#key#
3  HS API：execute_single
4  MC API：get

--整理自网上