• 如果网盘的下载失效,请在对应的文章下评论告知,我会尽快进行处理
  • 想要自己的评论显示漂亮的头像吗?可以在个人中心的个人资料里进行头像设置
  • 本站压缩包仅支持WinRAR 5以上版本解压,如果提示解压错误,请在本站搜索WinRAR下载更新
  •    4年前 (2013-12-03)  各种教程 |   抢沙发  553 
    文章评分 0 次,平均分 0.0

    在上周, Tomas 在 MySQL Percona Live Conference in London ,宣布了MySQL 5.7的版本--在只读的(Read-Only)测试环境,InnoDB 的 Memcached plugin的版本中,可以处理 每秒 1,000,000 次的查询。这个文章就是证实这个说法的。

    实际上,我至今也没有准确说法,到底可拓展性有多么的准确和有多少的性能限制在这里面..我们可以在最新的MySQL 5.7 中可以得到最大的性能提升,并且,并且可以让我们轻松的在“普通的”(normal)SQL 在只读的环境中(Read-Only workload) 测试到 500K QPS 。接下来,更多的性能提升在InnoDB Memcached Plugin代码中变为可能,然而,一切都是那么自然。尤其在Facebook团队,他们突破并展现出巨大的性能点。当然,Facebook给我们提供了 一个测试case,我们也用它来成功的提高了我们代码。最终,同样的测试案例会在下面的测试评分结果中展示出来;-)

    这个测试是在”独立“(standalone)模式上测试的。(包括服务器,客户端都在上面运行)。所以,我们使用我们实验室最大的HW box - 一个48核的机器。这个服务器能够迅速的给我们指出一个存在的,或者潜在的性能瓶颈(最有趣的是,大部分他们都是在memcached代码上面)。然 而,QPS 依赖于内存和CPU。因此,这台服务器是只有2Ghz的CPU 核,如果有存在其他更快的HW,你可能能得到更好的积分统计 :-)

    现在,比较 最好-最好 的QPS结果如下:

    在MySQL5.7中使用InnoDB Memcached插件实现每秒100万QPS

     

    曾经把MySQL5.6放上神坛,给它打上“有史以来最好的结果”这样的标签;-))——由于一部分的Memcached代码性能提高也会反过来提 升MySQL5.6的性能,所以我们也期望在5.6的下一版本中也能运行的良好。实际上,只需要MySQL5.7,你就可以达到一个很高的水平……

    在我在伦敦的Percona现场讨论会上,我曾经展示过下面这些图表——Memcached QPS是符合InnoDB的“dml_read/sec”的状态:

    在MySQL5.7中使用InnoDB Memcached插件实现每秒100万QPS

     

    这些图表代表着在“上一版”MySQL上所做的4个Memcached负载测试:

    #1运行在48核的机器上……——我们遇到了与MVCC相关的服务器冲突(在最新版的MySQL5.7中已经修复了)
    #2限制MySQL服务运行在16核的机器上,以降低这个冲突……——然后,我们遇到了事务冲突(这也在最新版的MySQL5.7中修复了)
    #3调整Memcached plugin,在一个独立的事务内部保持一些读操作——神啊,救救我吧,我又遇到了一些其他的冲突……
    #4限制MySQL服务运行在8核的机器上,看是否会降低冲突——事实表明,最大QPS有所提高(在32个用户的情况下),但是整体性能却更糟了……
    相反的,在最新版的MySQL5.7中,情况确实完全不同:

    在MySQL5.7中使用InnoDB Memcached插件实现每秒100万QPS

     

    这些图所表示的是两个测试:

    #1-运行在48核的机器上(不做太多评论;-))
    #2-调整了一些参数,在一个独立的内部事务中保持一些读取的操作,结果只有在QPS的峰值上稍微好点,其他方面没有什么区别。
    接下来为了更好的感受到QPS的差距,我们将这些测试结果放在一个图表中:

    在MySQL5.7中使用InnoDB Memcached插件实现每秒100万QPS

     

    你可以更形象的看到这两者的不同。

    图表的左半部分曲线代表的QPS水平都是在“旧版”的MySQL5.6/5.7上得到的。
    然后右半部分的曲线是在最新版的MySQL5.7上得到的。
    这项工作仍在进展中,关于在这个最新的MySQL 5.7版本中我们实现的巨大进步,我会让Sunny 和 Jimmy给你们提供其中所有深入的细节。

    我不知道这里的性能极限在于哪里。可能只存在于HW(HardWare)层面。我也不知道是否有足够庞大的HW来观察它;-)——现在经由一个单独的1Gbit网络链接,我们已经观察到超过700K QPS的 性能了,当这个来自于单独网络链路的极限峰值到达时,主要的麻烦却来自于客户端处理程序,而不是服务器——所以,看上去相比较“原始 的”Memcached本身来说,Memcached @InnoDB具有更好的伸缩性;-)——那么,当有几个网络链接启用(或者仅仅只是使用更快速的网卡)的时候可能会有什么样的性能呢——还有许多东西需 要去探索发掘的!而且RW(ReadWrite)工作负载性能也是另一项挑战;-)

      
     

    欢迎加入伤逝的安详博客2000人QQ群进行交流,点击加群     如果想请站长喝杯茶,点这里

    伤逝的安详网站是由系统与软件爱好者阿斯兰萨拉建立,旨在分享更多更好的软件、教程、资讯等内容。如果您有好的文章想在本站发布,欢迎注册后在个人中心进行投稿。

    发表评论

    表情 格式

    暂无评论

    切换注册

    登录

    忘记密码 ?

    切换登录

    注册