MySQL Fabric Performance Test

In previous post, I've introduced MySQL Fabric and give two video(1 2) to show how to use it. It is pretty simple and user-friendly. You can use it to manage a farm of MySQL servers. But I also pointed out that the XML-RPC protocol used by Fabric server may become a bottleneck. Now, I've tested it. And I would say my concern is justifiable and reasonable.

I can't directly use sysbench to test due to the fact that it is written by C. So I have to write it by myself. I choose Python as it is very suitable for writing a simple benchmark. The code can be download from here. It is pretty simple benchmark, just selecting data by primary key by a number of threads.

Since I test in one server, I have to configure Fabric Server, back store, MySQL servers all in one. The following picture is my whole MySQL Fabric architecture:

MySQL Fabric Performance Test-MySQL社区 Inside MySQL Group

I find that Oracle MySQL Python Connector is written fully by Python. So I compare the Oracle MySQL Connector with Python MySQLdb which is wrapped C API. The following table show the final result:

MySQL Fabric Performance Test-MySQL社区 Inside MySQL Group

As you can see it, when you connect using MySQL Fabric XML-RPC protocol. The performance is 1/5 ~ 1/4 than using direct MySQL protocol connection. In addition, MySQLdb is 1.2 ~ 1.5 times faster than Oracle Python MySQL Connector.

Another problem bother me about my test is that when doing benchmark under thread 128 or 512, it will raise following errors or something like that, which causes the QPS to decline dramatically. I've tune some parameter, like connect_attempts, connect_delay, ttl, but it does not help at all.

Reported faulty server to Fabric (2003: Can't connect to MySQL server on 'localhost:3309' (99 Cannot assign requested address))

I notice that Fabric Server protocol seems configurable in fabric.cfg. Currently it only supports XML-PRC. I hope MySQL Fabric can support a higher performance protocol and address the performance disparity between itself and Python MySQLdb. Only in this way, can MySQL Fabric be really and rapidly used in production environment.

Now I guess it's time for reading the code of MySQL Fabric.

发表评论

18 条评论
  • #12 GBvQf 

    这个更刺j激,准备好手纸哦 A 片。。 http://uVU.cc/itn6

  • #11 SpTUA 

    这个更刺j激,准备好手纸哦 A 片。。 http://uVU.cc/itn6

  • #10 WeIQm 

    这个更刺j激,准备好手纸哦 A 片。。 http://uVU.cc/itn6

  • #9 izbsX 

    这个更刺j激,准备好手纸哦 A 片。。 http://uVU.cc/itn6

  • #8 HFbFS 

    这个更刺j激,准备好手纸哦 A 片。。 http://uVU.cc/itn6

  • #7 akddy 

    万 c部 A 片 高c清 国产.日韩 288d.pw

  • #6 小白 

    奇怪,姜老师测的python mysql/connector, MySQLdb分别是什么版本,我当时测试的python mysql/connector要比MySQLdb好一些。

    • 姜 承尧
      姜承尧 

      版本应该没关系,都是最新的。python mysql connector是纯python写的,好处是没有依赖。MySQLdb是C的封装,性能会好,但是需要依赖mysql client库。你可以把你的测试结果发我一份看看

  • #5 DE4DJOE 

    Maxscale 和奇虎的atalas呢?

    • 姜 承尧
      姜承尧 

      他们是很好的中间件方案,不过第三方要使用可能会遇到些问题。关注官方的解决方案,Fabric会越来越完善的

  • #4 鲍峰 

    姜老师,一开始我以为FabricMySQLDriver驱动是通过语句去做路由,但现实的测试是如果不指定conn.setReadOnly(true),即使只有select语句,所有的查询还是只是在master上执行。但实际应用程序里面读写是混合在一起的,应用的改造难度太大。

    • 姜 承尧
      姜承尧 

      是的,不是透明读写分离机制

  • 板凳 磨叽_MySQL 

    我理解您说的只做管理操作是APP不通过fabric的connector连接数据库。如果只做管理操作的话,那么failover 时APP 怎么切换是个问题?还有如果fabric和master 之间的网络中断而APP 和master 之间的网络是正常的,那么fabric做了切换,是不是会造成数据不一致呢?

    • 姜 承尧
      姜承尧 

      前端还是需要有类似VIP这样的机制

  • 椅子 磨叽_MySQL 

    我们是为金融客户做开源服务的公司,数据库主要是MySQL 。但是如果用fabric 代替MHA的HA管理那么性能还是硬伤啊。哎纠结

    • 姜 承尧
      姜承尧 

      管理操作不需要很高的性能的。btw,你们公司叫什么?

  • 沙发 别他妈给机会 

    姜老师:fabric 我们也在测试,但是是在功能性的验证。但是看您的性能测试,觉得fabric 不能用啊在生产上,这个性能差距也忒大了

    • 姜 承尧
      姜承尧 

      是的,感觉现在还不成熟。不过用来进行HA的管理工作还是不错的,可以取代MHA这类工具。你们是什么企业?为什么需要Fabric?

相关文章
MySQL 8.0.3性能大杀器 —— CATS
MySQL 8.0.3性能大杀器 —— CATS
2017年MySQL数据库技术嘉年华 —— 有态度的技术大会
2017年MySQL数据库技术嘉年华 —— 有态度…
IMG社区MySQL技术沙龙南京站圆满结束
IMG社区MySQL技术沙龙南京站圆满结束
改朝换代:MySQL Group Replication
改朝换代:MySQL Group Replication
数据库行业的朋友圈内幕,不知道就没法混了
数据库行业的朋友圈内幕,不知道就没法…
Inside MySQL Group社区启用新LOGO
Inside MySQL Group社区启用新LOGO
Oracle MySQL ACE. Author of Inside MySQL and MySQL Core Series. Great at MySQL performance tuning、troubleshooting、systems availability and scalability、capacity planning, etc.

一触即发,2017年,数据库世界的诸神之战