没有两个站点是相同的。您确实需要使用像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.

当然pdo很好，但是它与mysql和mysqli相比的性能一直存在一些争议，尽管现在看起来已经固定了。

如果您考虑可移植性，您应该使用pdo，如果不考虑可移植性，则应该使用mysqli。它有一个面向对象接口、准备好的语句和pdo提供的大部分功能(除了可移植性)。

另外，如果真的需要性能，可以准备PHP 5.3中的MysqLnd驱动程序，它将与PHP更加紧密地集成，具有更好的性能和改进的内存使用(以及用于性能调优的统计数据)。

如果你有集群服务器(和youtube一样的负载)，Memcache是很好的，但我也会先尝试APC。

我的第一个建议是考虑这个问题，并在设计网站时牢记它，但不要走极端。通常很难预测一个新网站的成功，我认为你的时间最好花在早点起床，然后再优化它。

一般来说，Simple是快速的。 模板会降低您的速度。数据库会降低您的速度。复杂的库会降低您的速度。从数据库中检索模板并在一个复杂的库中解析它们——>时间延迟相互相乘。

一旦你有了基本的站点并开始运行，就可以做一些测试，告诉你应该把精力花在哪里。很难看出目标在哪里。通常，为了加快速度，你必须分解代码的复杂性，这会使代码变得更大，更难维护，所以你只在必要的时候才这么做。

根据我的经验，建立数据库连接是相对昂贵的。如果可以的话，不要在访问量最大的页面(如网站首页)上为普通访问者连接数据库。创建多个数据库连接非常疯狂，而且收效甚微。

没有两个站点是相同的。您确实需要使用像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.

第一个问题是，你真正期望它有多大?你们计划在基础设施上投资多少?既然你觉得有必要在这里问这个问题，我猜你希望从有限的预算开始。

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.

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

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

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