在这篇博文中,我们将讨论针对有载调压变压器工作负载的ProxySQL与最大规模.
继续我的只读基准测试系列（你可以在这里找到其他文章。percona .com/blog/2016/04/07/MySQl-5-7-sys板凳-OLTP-读取-结果-实时-快速/和http://www .percona .在这篇文章中,我想看看代理增加了多少开销。
在我看来,目前MySQL只有两个可靠的代理软件选项:ProxySQL和最大规模. 在过去,也有MySQL代理,但是现在它已经死了。 它的替代者，MySQl路由器,仍然处于非常早期的阶段,严重缺乏任何可以与ProxySQL和MaxScale竞争的特性。 这在未来很可能会改变。 当MySQL路由器增加更多特性时,我会重新评估它们！
为了测试代理,我将从一个非常简单的设置开始来衡量基本的性能特征。 我将使用在同一个盒子上运行的sys长凳客户端和代理。 sys长凳通过本地套接字连接到代理（为了最小的网络和传输控制协议开销)，代理通过10Gb网络连接到远程MySQL . 这样,代理和系统工作台共享相同的服务器资源。
其他参数：
- *处理器:56个逻辑*处理器线程服务器英特尔至强处理器E5-2683 v3 @ 2 .00GHz
- 系统工作台十个表x 10个行,帕累托分布
- 操作系统* Ubuntu 15 .10(狡猾的狼人(
- MySQL 5 .7
- MaxScale版本1 .4.1
- ProxySQL版本1 .2.0b
您可以在这里找到有关基准、脚本和配置的更多详细信息。com/Percona-Lab/benchmark-results/tree/201603-MySQl 55-56-57-RO/remote-OLTP-proxy-5月.
要考虑的一个重要参数是为代理分配多少*处理器资源。 ProxySQL和MaxScale都允许您配置它们可以使用多少线程来处理用户请求和路由查询。 我发现ProxySQL的16个线程和MaxScale的8个线程是最佳的（我也将在本文中展示MaxScale的16个线程). 这两个代理还允许您设置简单的负载平衡配置,或者在读写分离模式下工作。 在这种情况下,我将使用简单的负载平衡,因为在只读工作负载中没有读写分离要求).
第一个结果：与普通的MySQL 5相比，ProxySQL表现如何。7？
正如我们所看到的，ProxySQL的性能明显下降。 这是预料之中的,因为ProxySQL做了额外的工作来处理查询。 不过好的一面是，ProxySQL可以随着用户连接的增加而扩展。
ProxySQL的一个技巧是”快进”模式,这可以最大限度地减少处理开销（但缺点是,您不能使用许多其他功能). 出于好奇,让我们看看”快进”模式的表现：
现在让我们看看MaxScale会发生什么。 在显示下一个图表之前,让我不要说它包含”误差线“，误差线以竖线的形式出现。 基本上，”误差条”显示了一个标准偏差：条越长,在实验过程中观察到的变化越多。 我们希望看到更少的差异,因为这意味着更稳定的性能。
以下是MaxScale与ProxySQL的对比结果：
我们可以看到,在线程数量较少的情况下,两个代理几乎是相似的,但是MaxScale在扩展100个线程时比较困难。 平均而言，MaxScale的吞吐量更差,并且有很多变化。 总的来说,我们可以看到MaxScale需要更多的*处理器资源,并且每个请求使用更多的*处理器（与ProxySQL相比). 如果我们用16个线程（而不是8个(运行MaxScale，这是正确的：
拥有16个线程的MaxScale不能很好地处理工作负载,除了一些可见的可伸缩性问题,还有很多变化。
总而言之,这是一个相对性能的图表（普通的MySQL 5).7显示为1):
虽然该图表显示MaxScale的1-6个线程开销较少,但它不会随着用户负载的增加而扩展。