没有两个站点是相同的。您确实需要使用像jmeter和benchmark这样的工具来查看问题点在哪里。您可以花费大量的时间来猜测和改进，但是在您度量和比较您的更改之前，您不会看到真正的结果。

例如，多年来，MySQL查询缓存是我们所有性能问题的解决方案。如果你的站点很慢，MySQL专家建议打开查询缓存。事实证明，如果你有一个高的写负载，缓存实际上是瘫痪的。如果你不经过测试就打开它，你永远不会知道。

别忘了，缩放永远不会结束。处理10req/s的站点将需要更改以支持1000req/s。如果您足够幸运，需要支持10,000req/s，那么您的体系结构可能也会完全不同。

数据库

Don't use MySQLi -- PDO is the 'modern' OO database access layer. The most important feature to use is placeholders in your queries. It's smart enough to use server side prepares and other optimizations for you as well. You probably don't want to break your database up at this point. If you do find that one database isn't cutting, there are several techniques to scale up, depending on your app. Replicating to additional servers typically works well if you have more reads than writes. Sharding is a technique to split your data over many machines.

缓存

You probably don't want to cache in your database. The database is typically your bottleneck, so adding more IO's to it is typically a bad thing. There are several PHP caches out there that accomplish similar things like APC and Zend. Measure your system with caching on and off. I bet your cache is heavier than serving the pages straight. If it takes a long time to build your comments and article data from the db, integrate memcache into your system. You can cache the query results and store them in a memcached instance. It's important to remember that retrieving the data from memcache must be faster than assembling it from the database to see any benefit. If your articles aren't dynamic, or you have simple dynamic changes after it's generated, consider writing out html or php to the disk. You could have an index.php page that looks on disk for the article, if it's there, it streams it to the client. If it isn't, it generates the article, writes it to the disk and sends it to the client. Deleting files from the disk would cause pages to be re-written. If a comment is added to an article, delete the cached copy -- it would be regenerated.

我不认为自己会很快从MySQL转换过来——所以我想我不需要PDO的抽象功能。DavidM，谢谢你的文章，它们帮了我很多。

我是一个拥有超过1500万用户的网站的首席开发人员。我们很少遇到规模问题，因为我们很早就计划好了，并且经过深思熟虑。以下是我根据自己的经验提出的一些策略。

模式 首先，去规范化您的模式。这意味着您不应该使用多个关系表，而应该选择使用一个大表。通常，连接会浪费宝贵的DB资源，因为多次准备和排序会消耗磁盘I/O。尽量避免使用。

这里的权衡是您将存储/提取冗余数据，但这是可以接受的，因为数据和笼内带宽非常便宜(更大的磁盘)，而多个准备I/O则要昂贵几个数量级(更多的服务器)。

索引 确保您的查询使用了至少一个索引。但是要注意的是，如果频繁地编写或更新索引将会使您付出代价。有一些实验性的技巧可以避免这种情况。

您可以尝试添加其他未索引的列，这些列与已索引的列并行运行。然后，您可以有一个脱机进程，批量地在已索引的列上写入未索引的列。这样，你可以更好地控制mySQL何时需要重新计算索引。

像避免瘟疫一样避免计算查询。如果必须计算查询，请尝试在写入时执行一次。

缓存 我强烈推荐Memcached。它已经被PHP堆栈上最大的玩家(Facebook)证明了，而且非常灵活。有两种方法可以做到这一点，一种是在数据库层缓存，另一种是在业务逻辑层缓存。

DB层选项需要缓存从DB检索的查询结果。您可以使用md5()散列SQL查询，并在进入数据库之前将其用作查找键。这样做的好处是它很容易实现。缺点(取决于实现)是您失去了灵活性，因为您在缓存过期方面对所有缓存都一视同仁。

在我工作的车间中，我们使用业务层缓存，这意味着系统中的每个具体类都控制自己的缓存模式和缓存超时。这对我们来说工作得很好，但是要注意从DB中检索到的项可能与从缓存中检索到的项不一样，所以你必须同时更新缓存和DB。

数据分片 复制只能让你到此为止。很快，写操作就会成为瓶颈。为了弥补这一点，请确保尽早支持数据分片。如果你不这样做，以后你可能会想开枪自杀。

它的实现非常简单。基本上，您希望将密钥权限与数据存储分离。使用全局DB存储主键和集群id之间的映射。您可以查询此映射以获得一个集群，然后查询集群以获得数据。您可以缓存这个查找操作，这将使它成为一个可以忽略不计的操作。

这样做的缺点是可能很难从多个碎片中拼凑出数据。但是，你也可以设计自己的方法。

离线处理 不要让用户等待你的后端，如果他们没有必要的话。构建一个作业队列，并将任何处理移至脱机状态，将其与用户的请求分开。

我运营的网站每月有700万到800万的访问量。不是特别多，但足以让我们的服务器感受到负载。我们选择的解决方案很简单:数据库级的Memcache。如果数据库负载是您的主要问题，则此解决方案效果很好。

我们开始使用Memcache缓存最常用的整个对象和数据库结果。它确实起作用了，但它也引入了bug(如果我们更加小心的话，我们可能会避免其中一些bug)。

所以我们改变了我们的方法。我们构建了一个数据库包装器(使用与旧数据库完全相同的方法，因此很容易切换)，然后我们将其子类化以提供memcached数据库访问方法。

现在，您所要做的就是决定查询是否可以使用缓存(可能已经过期)的结果。用户运行的大多数查询现在都直接从Memcache中获取。例外情况是更新和插入，这对于主网站来说只发生在日志记录中。这个相当简单的措施减少了大约80%的服务器负载。

查看mod_cache, Apache web服务器的输出缓存，类似于ASP.NET中的输出缓存。

是的，我知道它还在试验阶段，但总有一天会最终实现。

使用Xdebug(推荐使用tj9991)之类的工具对应用程序进行性能分析绝对是必须的。盲目地进行优化是没有意义的。Xdebug将帮助您找到代码中真正的瓶颈，这样您就可以明智地花费优化时间，并修复实际上导致速度变慢的代码块。

如果您正在使用Apache，另一个可以帮助测试的实用程序是Siege。它将帮助您预测服务器和应用程序对高负载的反应，从而真正实现它的运行速度。

任何类型的PHP操作码缓存(如APC或其他)也会有很大帮助。