在你回答这个问题之前，我从来没有开发过任何流行到足以达到高服务器负载的东西。请把我当作(唉)一个刚刚登陆地球的外星人，尽管我知道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!优先考虑——但有什么经验是我应该注意的吗?
我运营的网站每月有700万到800万的访问量。不是特别多，但足以让我们的服务器感受到负载。我们选择的解决方案很简单:数据库级的Memcache。如果数据库负载是您的主要问题，则此解决方案效果很好。
我们开始使用Memcache缓存最常用的整个对象和数据库结果。它确实起作用了，但它也引入了bug(如果我们更加小心的话，我们可能会避免其中一些bug)。
所以我们改变了我们的方法。我们构建了一个数据库包装器(使用与旧数据库完全相同的方法，因此很容易切换)，然后我们将其子类化以提供memcached数据库访问方法。
现在，您所要做的就是决定查询是否可以使用缓存(可能已经过期)的结果。用户运行的大多数查询现在都直接从Memcache中获取。例外情况是更新和插入，这对于主网站来说只发生在日志记录中。这个相当简单的措施减少了大约80%的服务器负载。
没有两个站点是相同的。您确实需要使用像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.
