在你回答这个问题之前，我从来没有开发过任何流行到足以达到高服务器负载的东西。请把我当作(唉)一个刚刚登陆地球的外星人，尽管我知道PHP和一些优化技术。
我正在开发一个PHP工具，可以获得相当多的用户，如果它是正确的。然而，虽然我完全有能力开发程序，但当涉及到制作可以处理巨大流量的东西时，我几乎一无所知。所以这里有一些关于它的问题(也可以把这个问题变成一个资源线程)。
数据库
At the moment I plan to use the MySQLi features in PHP5. However how should I setup the databases in relation to users and content? Do I actually need multiple databases? At the moment everything's jumbled into one database - although I've been considering spreading user data to one, actual content to another and finally core site content (template masters etc.) to another. My reasoning behind this is that sending queries to different databases will ease up the load on them as one database = 3 load sources. Also would this still be effective if they were all on the same server?
缓存
我有一个用于构建页面和交换变量的模板系统。主模板存储在数据库中，每当一个模板被调用时，它的缓存副本(html文档)就会被调用。目前，我在这些模板中有两种类型的变量-静态变量和动态变量。静态变量通常是像页面名称，网站的名称-不经常改变的东西;动态变量是在每次页面加载时改变的东西。
我的问题是:
比如说我对不同的文章有评论。这是一个更好的解决方案:存储简单的注释模板，并在每次页面加载时呈现注释(来自DB调用)，或者将注释页面的缓存副本存储为html页面——每次添加/编辑/删除注释时，页面都会被重新检索。
最后
有人有任何提示/指针运行一个高负载的PHP网站。我很确定这是一种可行的语言——Facebook和Yahoo!优先考虑——但有什么经验是我应该注意的吗?
第一个问题是，你真正期望它有多大?你们计划在基础设施上投资多少?既然你觉得有必要在这里问这个问题，我猜你希望从有限的预算开始。
Performance is irrelevant if the site is not available. And for availability you need horizontal scaling. The minimum you can sensibly get away with is 2 servers, both running apache, php and mysql. Set up one DBMS as a slave to the other. Do all the writes on the master, and all the reads on the local database (whatever that is) - unless for some reason you need to read back the data you've just read (use master). Make sure you've got the machinery in place to automatically promote the slave and fence the master. Use round-robin DNS for the webserver addresses to give more affinity for the slave node.
在这个阶段，在不同的数据库节点上划分你的数据是一个非常糟糕的主意——然而，你可能会考虑在同一台服务器上的不同数据库上划分数据(当你超越facebook时，这将有助于跨节点划分)。
一定要确保你有适当的监控和数据分析工具来衡量你的网站性能和识别瓶颈。大多数性能问题都可以通过编写更好的SQL /修复数据库模式来解决。
将模板缓存保存在数据库上是一个愚蠢的想法——数据库应该是结构化数据的中央公共存储库。将你的模板缓存保存在你的web服务器的本地文件系统中——这样会更快，也不会降低你对数据库的访问速度。
使用操作码缓存。
花大量的时间研究你的网站和它的日志，了解为什么它运行得这么慢。
将尽可能多的缓存推到客户端。
使用mod_gzip可以压缩所有内容。
C.
我运营的网站每月有700万到800万的访问量。不是特别多，但足以让我们的服务器感受到负载。我们选择的解决方案很简单:数据库级的Memcache。如果数据库负载是您的主要问题，则此解决方案效果很好。
我们开始使用Memcache缓存最常用的整个对象和数据库结果。它确实起作用了，但它也引入了bug(如果我们更加小心的话，我们可能会避免其中一些bug)。
所以我们改变了我们的方法。我们构建了一个数据库包装器(使用与旧数据库完全相同的方法，因此很容易切换)，然后我们将其子类化以提供memcached数据库访问方法。
现在，您所要做的就是决定查询是否可以使用缓存(可能已经过期)的结果。用户运行的大多数查询现在都直接从Memcache中获取。例外情况是更新和插入，这对于主网站来说只发生在日志记录中。这个相当简单的措施减少了大约80%的服务器负载。
首先，正如Knuth所说，“过早的优化是万恶之源”。如果你现在不需要处理这些问题，那就不要去做，先专注于交付一些正确工作的东西。也就是说，如果优化不能等待。
试着分析你的数据库查询，找出什么是慢的，什么是经常发生的，并从中提出一个优化策略。
我会研究Memcached，因为很多高负载站点都使用它来有效地缓存所有类型的内容，而且它的PHP对象接口非常好。
在服务器之间分割数据库并使用某种负载平衡技术(例如，在具有必要数据的冗余数据库中生成1到#之间的随机数—并使用该数字确定要连接到哪个数据库服务器)也是提高效率的一种极好的方法。
在过去，对于一些相当高的负载站点，这些方法都非常有效。希望这能帮助你开始:-)
我是一个拥有超过1500万用户的网站的首席开发人员。我们很少遇到规模问题，因为我们很早就计划好了，并且经过深思熟虑。以下是我根据自己的经验提出的一些策略。
模式
首先，去规范化您的模式。这意味着您不应该使用多个关系表，而应该选择使用一个大表。通常，连接会浪费宝贵的DB资源，因为多次准备和排序会消耗磁盘I/O。尽量避免使用。
这里的权衡是您将存储/提取冗余数据，但这是可以接受的，因为数据和笼内带宽非常便宜(更大的磁盘)，而多个准备I/O则要昂贵几个数量级(更多的服务器)。
索引
确保您的查询使用了至少一个索引。但是要注意的是，如果频繁地编写或更新索引将会使您付出代价。有一些实验性的技巧可以避免这种情况。
您可以尝试添加其他未索引的列，这些列与已索引的列并行运行。然后，您可以有一个脱机进程，批量地在已索引的列上写入未索引的列。这样，你可以更好地控制mySQL何时需要重新计算索引。
像避免瘟疫一样避免计算查询。如果必须计算查询，请尝试在写入时执行一次。
缓存
我强烈推荐Memcached。它已经被PHP堆栈上最大的玩家(Facebook)证明了，而且非常灵活。有两种方法可以做到这一点，一种是在数据库层缓存，另一种是在业务逻辑层缓存。
DB层选项需要缓存从DB检索的查询结果。您可以使用md5()散列SQL查询，并在进入数据库之前将其用作查找键。这样做的好处是它很容易实现。缺点(取决于实现)是您失去了灵活性，因为您在缓存过期方面对所有缓存都一视同仁。
在我工作的车间中，我们使用业务层缓存，这意味着系统中的每个具体类都控制自己的缓存模式和缓存超时。这对我们来说工作得很好，但是要注意从DB中检索到的项可能与从缓存中检索到的项不一样，所以你必须同时更新缓存和DB。
数据分片
复制只能让你到此为止。很快，写操作就会成为瓶颈。为了弥补这一点，请确保尽早支持数据分片。如果你不这样做，以后你可能会想开枪自杀。
它的实现非常简单。基本上，您希望将密钥权限与数据存储分离。使用全局DB存储主键和集群id之间的映射。您可以查询此映射以获得一个集群，然后查询集群以获得数据。您可以缓存这个查找操作，这将使它成为一个可以忽略不计的操作。
这样做的缺点是可能很难从多个碎片中拼凑出数据。但是，你也可以设计自己的方法。
离线处理
不要让用户等待你的后端，如果他们没有必要的话。构建一个作业队列，并将任何处理移至脱机状态，将其与用户的请求分开。
