我正在建立一个PHP网站，但目前我使用的唯一PHP是在某些页面上包含了六个左右。 (我最终可能会使用一些数据库查询。)

与静态HTML相比，简单的include()语句是否关心速度或者扩展性？什么样的事情倾向于导致站点陷入困境？

解决方案

当然include()比静态页面要慢。但是，对于现代系统，即使很长一段时间，我们也不太可能将其视为瓶颈。使用的好处包括让你的网站的公共部分最新大于微小的性能损失，在我看来(具有不同的导航一个页面上，因为你忘了更新它会导致糟糕的用户体验，以及约因而不好的感觉你网站/公司/任何网站)。

使用缓存实际上并不会帮助缓存代码比仅仅包含一个()慢。如果我们要进行计算密集型计算(在网页上很少见)，或者从数据库中获取数据，那么唯一使我们受益的时间就是缓存。

不，包括，很好，没有什么可担心的。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

我们可能需要考虑在某些时候调整缓存头，但是除非命中率很高，否则应该没问题。假设这都是静态数据，我们甚至可以考虑将整个网站转换为静态HTML(最简单的方法：编写一个脚本，通过Web服务器获取每个页面并将其转储到匹配的dir结构中)

大多数Web应用程序都受到数据库速度(或者外部存储量的限制，但是是数据库的9/10倍)的速度限制，很少引起应用程序代码的关注，而且听起来不像我们正在做我们需要担心的任何事情。

严格来说，直接HTML总是比服务器端方法更快，因为服务器不必对代码进行任何解释。

为了回答更大的问题，有很多事情会导致网站瘫痪。与PHP相比，对于何时代码导致问题没有特定的阈值。 (请记住，雅虎的许多站点都是PHP驱动的，因此不要认为PHP无法扩展)。

我注意到的一件事是，最慢的PHP驱动网站是那些包含超出显示特定页面所需内容的网站。 OSCommerce(oscommerce.com)是最受欢迎的PHP驱动的购物车之一。但是，它有一个坏习惯，那就是在每个页面上都包含其所有核心功能(以防万一)。因此，即使我们不需要显示"信息框"，也会加载该函数。
另一方面，有许多PHP框架(例如CakePHP，Symfony和CodeIgniter)采用"按需加载"的方法。

我建议以下几点：

• 所包含的功能不要超过特定页面所需的功能
• 将基本功能分开(尽可能使用MVC方法)
• 如果我们认为自己将嵌套包含(例如，页面A包含文件B，其中包含文件C)，请使用require_once而不是包含。这样可以避免多次包含同一文件。如果找不到文件，它也会停止该过程。从而进行故障排除；)
• 如果可能，将静态页面作为HTML缓存-避免在情况不变时重新解析

在需要时添加JayTee提到的加载功能。如果我们没有使用任何自动执行此操作的框架，则可能希望研究一下PHP5中引入的__autoload()功能，当实例化尚未加载的特定类时，可以调用我们自己的逻辑。这使我们有机会包含()一个按需定义该类的文件。

在就如何构造站点代码做出长久的决定之前，我建议我们先阅读一下"模型-视图-控制器"设计模式。尽管还有其他方面，但这一领域似乎在Web开发领域中已经获得了很大的发展，并且肯定还会存在一段时间。在就哪种设计最适合需求做出最终决定之前，我们可能需要看看Martin Fowler在其《企业应用程序体系结构》中建议的其他一些设计模式。

根据项目的大小和范围，我们可能希望使用现成的PHP框架(例如Zend Framework或者PHP On Trax)，或者决定构建自己的解决方案。

特别是关于HTML内容的呈现，我强烈建议我们使用某种形式的模板，以使业务逻辑与显示逻辑分离。我发现开发中的一条简单规则在需要更改其中一项时为我节省了工作时间。我使用过http://www.smarty.net/">Smarty，我知道那里的大多数框架都有自己的模板系统或者提供了一个插件体系结构，可让我们使用自己喜欢的框架在研究可能的解决方案时，我建议我们寻找一种能够创建缓存版本的解决方案。

最后，如果我们担心后端的速度，那么我强烈建议我们考虑最小化后端数据存储(无论是数据库还是系统文件)调用的方法。尽量避免一次加载和呈现太多内容(例如，存储在包含数百条记录的表中的大型报表)。如果可能，寻找使用户界面一次加载较小位数据的方法。
并且，如果我们特别关注html内容及其CSS，Javascript或者其他依赖项的实际加载时间，则建议我们查看Yahoo!的建议。

我们可以做的最大的事情就是加快操作速度，例如使用APC这样的操作码缓存。 Wikipedia上有出色的列表和说明。

就简单的include而言，请注意不要在每个请求中包含太多文件，因为磁盘I / O可能导致应用程序无法很好地扩展。几十个include应该没问题，但是将我们最常包含的文件打包到一个脚本中通常是一个好主意，因此我们只有一个include。在这里和那里不需要加载一些类的内存开销要比包含数百个较小文件的磁盘I / O开销要好。

听起来我们正在参与一些过早的优化。如果未构建应用程序，则虽然应该很好地了解性能问题，但主要的问题应该是编写应用程序。

包括生活中的事实。不用担心数量，不必担心代码井井有条(如果我们不知道我在说什么，那么看一下Zend Framework类文件的结构，PEAR文件夹结构是一件很可爱的事情)。

专注于以合理的抽象量编写应用程序。将所有数据库调用分组到一个(或者多个)类中，以便最大程度地减少代码重复(KISS原理和所有)，并且当需要重构和优化查询时，它们将位于中心。也开始进行一些单元测试以防止回归。

一旦应用程序启动并运行，不要再问我们哪个更快或者更更好，因为这取决于每个应用程序的瓶颈。事实证明，即使我们有很多包含项，循环也会占用时间，或者其他。一旦代码启动并运行，请使用XDebug并分析代码。查找占用大量时间的代码段，然后进行重构。如果现在过多地关注include和include_once之间的性能问题，那么当那些同步运行的curl请求正在吃早餐时，我们将最终追上一个幽灵。

尽管同时，最好的建议是浏览php.net手册，并确保是否有内置函数执行我们要尝试的操作，然后使用它！ PHP的基于C的扩展将永远比我们可以编写的任何PHP代码都要快，并且我们会惊讶于我们尝试做的事情已经完成了多少。

但是，我再强调不过，过早的优化是很糟糕的！！！只需以良好的抽象水平启动应用程序，对其进行概要分析，然后解决实际消耗的时间，而不是解决我们认为可能会消耗时间的问题。