我正在寻找有关如何扩展我们的服务器设置的资源。
我们目前在英国拥有一台 Rackspace 专用服务器，其规格如下：
HPDL385_G2_PrevGen
HP 单双核 Opteron 2214 (2.2Ghz)
4GB RAM
2x 10,000 SCSI 驱动器（RAID 1）
我们的流量高达每月55万UV。
该网站运行的是 PHP 和 MySQL 设置。数据库受到了极大的打击，我们有许多连接多个表的复杂查询。
我们正在使用 APC 进行 PHP 缓存。
我现在已经尽可能多地对数据库和查询进行了优化，并且想知道下一步应该怎么做......
我查看过 memcache，但我的印象是它需要大量的 RAM，理想情况下还需要一个专用的盒子……
那么下一步是不是要有两个框；一个用于数据库，一个用于 Apache？还是我忽略了某个步骤。
我们的负载通常在 2 左右，但是现在已经达到 20 了！
Munin 的一些图表：
答案1
购买一些硬件，但将其放在测试实验室而不是数据中心。然后在各种硬件/软件组合上测试您的应用程序，直到找到一个可以满足您要求的合理组合。
当然，您需要设计某种东西来针对运行应用程序测试副本的生产数据库创建虚假流量。但谁说这会很容易呢？
如果您不这样做而只是在生产中做一些事情，那么您就不知道它是否会起作用，并且您可能已经花费了大量的工程精力来实现诸如缓存之类的东西（这会带来相当多的错误！）而没有帮助。
测试、测试、再测试。除非您有良好的性能数据表明硬件/软件更改可能会显著改善问题，否则不要将其投入生产。工程工作很昂贵，测试硬件则不然（尤其是）。
Memcached 只是一种选择，在数据库缓存达到最佳工作状态之前，您可能不需要考虑它。这意味着将其放在专用的（当然是 64 位）盒子上，并配备合理数量的 RAM（不是 4G - 如今笔记本电脑都有 4G；32G 肯定是可以承受的），并进行适当的调整。
您没有提到数据库有多大，但如果可行，您会希望尝试将其完全放入内存中（或至少是热位）。将数据库完全放入内存中将使读取 IO 操作完全消失，从而不再成为瓶颈。
分析数据库查询。有很多工具可以完成此操作 - 您应该能够在测试环境中模拟生产负载。诀窍是避免慢查询并确保经常执行的查询速度快。
如果您的性能问题与 IO 同步有关，因为您为数据库执行了太多事务，请确保您使用的是运行正常的电池供电 RAID 控制器（请与您的供应商讨论）。它们比非电池供电的 RAID 控制器提供更多的 IO 写入操作（因为数据只需要在操作系统获得确认之前到达缓存）。或者，如果您的数据不那么重要，请考虑放宽数据库的持久性参数（innodb 提交时同步）。
答案2
通过研究缓存解决方案，正如许多其他人所建议的那样，您可以预期最终会得到当前负载的约 10％，甚至更少。
但是，这取决于您在机器上运行的服务类型。使用 memcached 可以做很多事情，而不需要太多的 RAM。
您应该尝试分析哪些数据库查询耗时最长，方法是使用MySQL 的慢查询日志（或与你的数据库相当的工具），或者使用如下工具麦托普。另外，MySQL 的EXPLAIN SELECT语法可能有帮助。
缓存一些选定的 MySQL 查询的结果（即使只是很短一段时间）确实可以大大提高您的性能。
答案3
我做了很多性能和扩展工作，我发现：
每个应用程序负载都是独一无二的
诸如添加更多内存、获取另一台服务器、执行 y、尝试 x 等通用响应通常都令人沮丧，并且会导致复杂的设置。
衡量正确的事物
最大的挑战之一是确定哪些基准很重要。这通常需要退后一步，你必须站在客户的立场上。有时，简单的网站设计会改变，这对网络访问者来说意味着巨大的好处。这就是为什么我喜欢 YSlow! 这样的工具，它更关注最终用户的体验而不是服务器级别。一旦你决定了适合你网站的基准，你就可以开始调整了。基准可能是总页面加载时间、总页面大小、缓存效率、网站延迟等。你必须选择适合你的应用程序的基准。
螺母和螺栓
一旦你跟踪了正确的基准，就从非常低的水平开始。我喜欢使用 sysstat。你可以从 sysstat 获得大量信息，并帮助你梳理出哪个系统可能限制了整体应用程序性能。通常，我将性能问题归结为：
- 网络堆栈
- 内存堆栈
- 磁盘输入输出
- 应用层
- 操作系统层
使用 sysstat 和其他工具，您可以开始仔细分析并找出限制性能的系统。
例如，我曾见过负载过重的服务器由于应用程序配置不当而出现故障。缓存不良、静态内容缺少过期标头、使用 HTTP 而不是文件包含等都会导致应用程序性能不佳。修复这些应用程序问题不需要更改硬件。在其他情况下，尽管有大量缓存，但磁盘仍达到最大容量。迁移到更快的磁盘解决了该问题。
重复上述步骤
在应用程序调优过程中，你经常会发现一个瓶颈，但结果却发现另一个瓶颈。这就是为什么我建议尝试监控你正在调优的内容。
例如，假设您修复了磁盘 IO 问题，但您的应用程序仍然很慢。您可能认为自己的努力白费了，但实际情况是，您只是遇到了另一个瓶颈。通过仔细监控磁盘 IO，即使您的重要应用程序性能监视器没有变化，您也可以确保正在改进磁盘 IO。
获得正确的工具
确保你使用的工具适合这项工作。监控、测试、基准测试、分析和其他优化技术都有各种工具。找到最适合你情况的工具。
经验法则
虽然每个应用程序都是独一无二的，但我确实找到了一些标准的起点：
- 记忆数据库热爱记忆
- 磁盘 io 除了 raid 10 之外的任何设备都可能损害数据库性能
- 错误的优化——大价值并不意味着高性能
- 应用程序——将糟糕的应用程序设计归咎于服务器
您的下一步
如果您没有找到瓶颈，添加服务器可能没有多大帮助。要解决磁盘 IO，您可能需要另一台服务器或 SAN。如果您有 RAM 瓶颈，另一台服务器只能通过添加更多 RAM 来解决问题。与仅为现有服务器添加更多 RAM 相比，这是相当昂贵的举措。
快速解决
过度部署。当应用程序堆栈似乎是问题所在时，我不得不这样做。基本上是加载 CPU、RAM 和磁盘 IO（RAID 10、15K SCSI 或 SSD）。在硬件上大干一场，然后开始调优。这可以让你维持下去，直到你解决问题。
答案4
如果您有足够的可用 RAM，那么 memcached 甚至在同一个机器上也能帮到您。尝试缓存几个最繁重的查询，看看会发生什么。此外，Apache 太重了，请使用 nginx 或 lighttpd（对于通过 FastCGI 工作的 PHP 应用程序，请参阅php-fpm）。