当前位置: 首页 > 分布式系统 > 正文

HandlerSocket 测试

关键字:
1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

libmysql w/ prepared statements (5.1.56) (Ryan’s Numbers)

samples	%	symbol name
18054	4.1415	String::copy()
14223	3.2627	make_join_statistics()
11934	2.7376	JOIN::optimize()
10140	2.3261	my_wc_mb_latin1
7152	1.6407	my_utf8_uni
7092	1.6269	Protocol::send_fields(List*, unsigned int)
6530	1.4980	JOIN::prepare()
6175	1.4165	Protocol::store_string_aux()
5748	1.3186	create_ref_for_key()
5325	1.2215	mysql_execute_command(THD*)
-        Still lots of time with SQL overhead(not parsing)

因为各个版本没有什么复杂的设计实现上的变化,尽管设计的Case用例不同,但是两者的结论是相似的,这也和Yoshinori Matsunobu作出决策的结论一致,不一致才怪。

总结

在上篇博客介绍其原理时我们知道,HandlerSocket主要的贡献是绕过了SQL层的解析,从而减少了CPU的使用率,降低了延迟等待时间,当然其在请求的批量处理以及网络协议的压缩等方面也做了优化,可以参考下面的分享,不错的内容:HandlerSocket Plugin For MySQL可以进一步降低磁盘和网络IO,因此提高了响应时间和处理能力。而且,其在buffer pool方面必定会有下一步动作。从实测的结果看,基本CPU利用率基本稳定在40%-50%,相比降低了20%以上,效果十分的显著,对于查询则更加明显。

此时,有 Vadim Tkachenko同学会对应用SSD或Fushion IO来检测系统IO对整体吞吐的影响程度感兴趣,验证了当内存不足以装下所有数据,IO成为瓶颈时,系统整体吞吐会有一个大的波动,我猜想这也是大部分同学反应达不到Yoshinori Matsunobu所吹嘘的700k性能的原因,还有Schema的设计也是非常重要的因素。总之,任何的性能数据都是有场景限制的,而大部分官网所公布的数据多是理想场景中的最佳性能,实在不足以为衡量选型的重要依据。

本文固定链接: http://www.chepoo.com/handler-socket-mysql-slowly-2.html | IT技术精华网

HandlerSocket 测试:等您坐沙发呢!

发表评论