您正在进入一个广阔而广泛的优化世界，并且肯定没有一种适合所有需求的方法。
定义绩效
您是指单个用户的页面加载时间，还是整体容量/总并发时间？两者非常不同-并不严格相关。快速存储容量有限是完全有可能的。或容量大的慢商店。
因此，在处理任何一种性能时：
- 单用户感知页面加载时间
- 总容量/并发
您必须使用各自的解决方案独立解决每个问题-尤其是因为每个都有各自的瓶颈。
让我们假设您与一台合格的主机配合使用，该主机已经为商店优化了服务器的其他方面。
单用户感知页面加载时间
是MySQL的瓶颈
。不是直接的。在所有情况下，在测试页面加载时间时，所有这些都与延迟有关-仅会命中缓存。因此，这里的关键是使延迟最小化。
- 适当地 调整MySQL缓存的大小（没有正确的答案，我们每个商店每月都会对设置进行完全不同的调整）
- 减少网络延迟。对于64字节帧；10Mbps为51.2µs，100Mbps为5.12µs，1Gbps为4.096µs。仅从100Mbps过渡到1Gbps，就可以提高20％。s1
- 增加网络容量。Web和DB服务器之间每秒要交换许多兆字节（通常超过10MB / s），因此s1至少需要100Mb / s，您会感到惊讶。或者，只需将数据库服务器移动到本地。
- 使用SOLR。外部引擎有时更适合，对于较大的目录，SOLR当然更快（我要强调的是，较大的目录）。甚至未经调整的SOLR也会比MySQL更快地产生分层的导航和搜索结果。
但是这些更改将对页面加载时间产生微小的影响-瓶颈确实在其他地方。
- 调整应用程序。Magento在构建集合和缓存它们的方式方面存在一些相当大的错误；我们遇到了许多可能影响性能的重大核心代码问题。在某些情况下，只需删除分层导航结果上的产品计数显示，就可以减少加载大集合的2 秒时间。
- 查看MySQL慢日志。检查慢查询并根据需要添加索引。使用带有和不带有适当索引的多个联接运行复杂查询之间的差异可能是数十秒。
应用程序是瓶颈。不是软件。因此，与任何 MySQL配置更改相比，仅改进核心代码或减轻模板的负担将对性能产生更大的影响。
我们不会打扰什么
- 更改存储引擎。MariaDB和Percona共享同一个InnoDB引擎-Percona XtraDB。它们可以被视为相同。就单个查询执行时间而言-性能将完全反映出原始MySQL构建。这在负载/并发下起作用。
- 运行一个MySQL从站。除非从站在物理上距离更近（从网络角度来看），或者从站的硬件比主站更好，否则这不会提高性能。这在负载/并发下起作用。
- 运行外部数据库服务器。到目前为止，这是我们看到的许多主机/代理机构反复发出的最糟糕的建议。除非您在硬件/资源上达到顶峰或拥有多个Web服务器（阅读：高可用性），否则在Magento商店的本地计算机上使用MySQL是一个好主意。它减少了所有网络开销和延迟。即使是100Gb / s的网络（是的，每秒100吉比特）也不会与本地unix套接字的原始卷，吞吐量和延迟进行比较。
s1仅适用于单独的数据库服务器。不适用于本地数据库服务器。
总容量/并发
是MySQL的瓶颈吗
？但是只有在您将PHP的性能和容量提高到使MySQL变慢的程度时，才可以这样做。如果您已经正确配置 了Varnish和FPC （不要让我们开始尝试使用任何一种尝试失败的次数），那么MySQL确实成为了瓶颈。
因此除了上述修改。
- 更改MySQL引擎。XtraDB在负载下可以表现出色，并且确实比现有的MySQL发行版显示出真正的优势。
- 随时了解MySQL。5.5在负载下的性能优于5.0。
- 更改PHP MySQL驱动程序。PHP 5.3和更高版本具有本机MySQL驱动程序，但是在某些情况下，我们发现PHP 5.2具有单独的驱动程序，其性能优于Magento的MySQLND。自己测试
- 更改搜索引擎。将搜索移至SOLR / Sphinx（甚至某些第三方外部服务）可以真正减轻非交易负载的负担（即，人们不下订单）
- 更改分层的导航引擎。同样，SOLR是用于分层导航的出色引擎，并且由于其非锁定性质，其运行速度比MySQL快得多。
- 添加一个MySQL从站。这确实有助于浏览（非事务性）负载，但并不能帮助您每小时处理更多订单-因为它依赖于主服务器来处理和复制此数据
我们不会打扰什么
- 硕士/硕士。由于主站/从站设置的硬件饱和非常高的临界点（每小时超过1000个订单）-我们从来没有发现在生产中使用主站/主站的要求。我们已经进行了广泛的测试，但是从性能的角度来看，它从来没有发现有优势，而且由于母带/母带的固有风险和问题，这根本不值得。
读取与写入可扩展性
最后一段实际上指向了读写可伸缩性的关键领域。随着越来越多的从机的添加，读缩放可以无限无限制地执行，而不会造成太多的复杂性。
考虑到Magento的读写比约为0.1％-考虑写应该不是太大的问题。这就是为什么我不介意提及MySQL Cluster及其聪明的功能，例如自动分片（将表分割到单独的机器上）。
硬件，硬件，硬件
在改进方面，硬件很容易是最快的答案，因此，在以上两种情况下，我都没有故意提到硬件。
但是，如果您的基础硬件不足，那么世界上所有的软件更改都不会起作用。那可能意味着...
- 缓冲区有限的低质量开关
- 过度饱和的网络链接
- 地理位置遥远的服务器
- 不良的网络QoS / CoS
- RAM总量有限
- 低内存带宽RAM
- 低IOP HDD子系统
- 软件RAID控制器
- 低时钟速度的CPU
- 低带宽芯片组
- 硬件虚拟化（除内核级虚拟化外，几乎所有类型）
如今，在硬件上实际可扩展的数量有很高的上限。让我们忽略“在云中”无限扩展的神话，因为云硬件往往相当中等。例如，亚马逊的旗舰机型只有12核@ 3.3GHz。但是除此之外，还有一些非常强大的服务器可用- 我们的顶级服务器具有160个内核和2TB（是，太字节）的RAM。我们还没有看到任何人能够超越此功能。
因此，在您甚至需要考虑水平缩放之前，您就拥有了很大的垂直缩放范围。
永远移动的目标
值得一提的是，在追求性能的过程中，瓶颈将一直存在。
对于Magento的库存商店。
打开缓存。PHP是瓶颈
添加后端缓存。PHP是瓶颈
添加应用程序级的全页缓存。PHP是瓶颈
添加服务器级前端缓存（例如Varnish）。MySQL是瓶颈
添加替代搜索/分层导航引擎（例如SOLR / Sphinx）。PHP是瓶颈
添加更多应用程序服务器。MySQL是瓶颈
添加MySQL从站。前端缓存是瓶颈
添加更多前端缓存服务器。PHP是瓶颈
添加更多应用程序服务器。SOLR /狮身人面像是瓶颈
Etcetera。
这几乎成为重复冲洗的情况。但是要清楚地理解的是，MySQL当然不是优化的第一个调用端口-实际上仅在MySQL与PHP成比例地消耗更多CPU时才起作用-并且只有在同时使用FPC和Varnish时才会发生这种情况并且服务器纯粹是在处理订单，而没有其他（因为其他所有内容都在缓存中）。
不要盲目地进行更改
只需添加一个MySQL从站即可，因为您已经阅读了我们上面所说的内容，这将对您有帮助，可能会在很大程度上降低您的性能和可靠性。拥塞的网络，低规格的从属服务器甚至不正确的设置都可能导致复制问题，从而使您的存储比开始时的速度慢-或导致主从服务器之间的同步问题。
透视事物-一些现实世界的例子。
示例1-每小时300个订单
我们使用以下硬件每小时可以处理300个订单 ; 而且只有在那个临界点时，我们才感到需要添加专用的MySQL服务器和本地MySQL从站。
1个服务器
CPU：2个Intel E5-4620
RAM：64GB硬盘：4个80k IOP / s SSD
RAID：硬件RAID 10
Magento版本：Magento EE
操作系统：MageStack
在整个过程中，平均负载保持在3.00以下。
示例2-每小时180个订单
就在两天前，我们的新客户很容易吸收了巨大的流量高峰。使用单服务器和Magento Community Edition每小时处理180个订单。
1个服务器
CPU：2个Intel E5-4620
RAM：64GB硬盘：4个80k IOP / s SSD
RAID：硬件RAID 10
Magento版本：Magento CE
操作系统：MageStack
网站：Wellgosh.com
在整个时间内，平均负载保持在6.00以下。在这种情况下，负载较高，这可以归结为两个因素。
- 没有像示例1那样执行存储侧调整
- 缺乏应用程序级别的FPC
鉴于这一点的近期性，我们仍然可以获得详细的统计数据，以通过图表的方式提供一些反馈。这些讲述了一个很好的故事，说明如何在单独的Magento体系结构的关键组件（负载均衡器，Web服务器，数据库服务器等- 使用MageStack）之间分配负载。
因此，从头到尾……您要查看的日期是2月22日凌晨12:00。
防火墙数据包
清漆交通
Nginx流量
MySQL加载
CPU负载
最重要的是负载分配
该图像可以说明一切。而且MySQL当然不是负担- 至少现在还不是。因此，我们的建议将您的性能问题集中在其他地方，除非您每小时处理数千个订单。
并总结一下
进行性能更改并非“一刀切”。这是分析您当前的瓶颈并进行细微更改/调整以适合您的商店和基础架构的情况。
除了性能，使用Percona还有其他好处
我们几乎完全使用Percona XtraDB。我们运行专门为Magento开发的自定义编译的MySQL版本，并在此过程中咨询了Percona。但是，影响选择的不仅是性能。
- Percona工具包
- pt-query-digest
- xtrabackup
- 等等
- Percona释放频率
- Percona咨询支持
- 热缓存重新启动并保留InnoDB池
以及更多。因此，在MySQL上使用它不仅具有性能方面的其他优势。实际上，在追求性能和稳定性方面，MySQL一直是我们关注的最少的问题。
归因：wellgosh.com，sonassi.com，iebmedia.com。