在你回答这个问题之前,我从来没有开发过任何流行到足以达到高服务器负载的东西。请把我当作(唉)一个刚刚登陆地球的外星人,尽管我知道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!优先考虑——但有什么经验是我应该注意的吗?


当前回答

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

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

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

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

其他回答

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

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

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

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

关于缓存的观点是正确的;这是构建高效应用程序中最简单也是最重要的部分。我想补充的是,虽然memcached很棒,但如果您的应用程序位于单个服务器上,那么APC大约要快5倍。

MySQL性能博客上的“缓存性能比较”有一些关于这个主题的有趣的基准测试——http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/。

我不敢相信居然没有人提到这个:模块化和抽象。如果您认为您的站点将不得不扩展到许多机器,那么您必须这样设计它!这意味着一些愚蠢的事情,比如不要假设数据库在本地主机上。它还意味着一些一开始会很麻烦的事情,比如编写数据库抽象层(像PDO,但要轻得多,因为它只做您需要它做的事情)。

这意味着在一个框架下工作。您将需要对代码进行分层,以便稍后通过重构数据抽象层(例如,通过告诉它某些对象位于不同的数据库中)来获得性能,并且代码不必知道或关心。

最后,要注意内存密集型操作,例如不必要的字符串复制。如果你能保持PHP的内存使用较低,那么你的web服务器就会得到更好的性能,当你采用负载平衡的解决方案时,这是可以扩展的。

回复: PDO / MySQLi / MySQLND

@gary

你不能说“不要使用MySQLi”,因为他们有不同的目标。PDO几乎就像一个抽象层(尽管实际上不是),它的设计目的是为了方便使用多个数据库产品,而MySQLi则专门针对MySQL连接。在将PDO与MySQLi进行比较的情况下,说PDO是现代访问层是错误的,因为你的声明暗示了进程已经是mysql -> MySQLi -> PDO,而事实并非如此。

MySQLi和PDO之间的选择很简单——如果你需要支持多个数据库产品,那么就用PDO。如果你只使用MySQL,那么你可以在PDO和MySQLi之间选择。

那么你为什么选择MySQLi而不是PDO呢?见下文……

@ross

You are correct about MySQLnd which is the newest MySQL core language level library, however it is not a replacement for MySQLi. MySQLi (as with PDO) remains the way you would interact with MySQL through your PHP code. Both of these use libmysql as the C client behind the PHP code. The problem is that libmysql is outside of the core PHP engine and that is where mysqlnd comes in i.e. it is a Native Driver which makes use of the core PHP internals to maximise efficiency, specifically where memory usage is concerned.

MySQLnd是由MySQL自己开发的,最近已经登陆到PHP 5.3分支,该分支正在RC测试中,准备在今年晚些时候发布。然后你将能够使用mysqnd与MySQLi…但PDO不行。这将使MySQLi在许多方面(不是所有方面)都有性能提升,如果你不需要像PDO那样的抽象功能,它将成为MySQL交互的最佳选择。

也就是说,mysqnd现在可以在PHP 5.3中用于PDO,因此您可以从ND到PDO的性能增强中获得优势,然而,PDO仍然是一个通用的数据库层,因此不太可能像MySQLi那样从ND的增强中获益。

这里可以找到一些有用的基准,尽管它们是2006年的。你还需要注意类似这个选项的事情。

在MySQLi和PDO之间做出选择时,有很多需要考虑的因素。事实上,除非你的请求数量非常高,否则这并不重要,在这种情况下,使用一个专门为MySQL设计的扩展比使用一个抽象的东西并恰好提供MySQL驱动程序更有意义。

这不是哪一个最好的简单问题,因为每一个都有优点和缺点。您需要阅读我提供的链接,然后做出自己的决定,然后测试并找出答案。我在过去的项目中使用过PDO,它是一个很好的扩展,但我对纯性能的选择是MySQLi与新的MySQLND选项编译(当PHP 5.3发布时)。

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

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

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

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

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

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

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

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

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

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

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

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

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