优化PHP框架加载

我有一个用PHP编写的定制应用程序框架，我的任务是对其进行优化。这个框架是一个共享的代码库，它加载MVC“模块”以提供各种功能。每个模块都是一个目录，其中包含用于控制器和模型的多个PHP类以及用于视图的PHP文件

整个框架加载几乎所有的请求，包括图像和样式表。这是因为模块设计为自包含的包，其中可能包含图像、样式表、Java脚本或其他静态文件。因此，在处理通常非常简单的请求时会有开销，因为系统必须加载所有模块，以确定哪些模块可以从中提取静态文件

处理任何给定URI的一般过程如下所示：

包括所有基本系统类

设置了一个全局异常处理程序和一些全局变量

读取系统范围的配置文件。（这是一个用PHP语句填充的文件，用于设置配置变量）

已建立到数据库的连接

通过opendir（）扫描modules文件夹，验证每个模块是否有效且没有语法错误，然后将其包括在内。

加载第二个配置文件，用于设置模块的配置

创建每个模块的一个新实例（调用它的_construct（）方法，并可能创建其他数据库连接，执行单独的启动例程，等等）

检查URI并将其传递给相应的模块 步骤1-7几乎总是完全相同的。除非安装新模块或更改配置文件，否则它们将始终执行完全相同的操作。我的问题是，可以做些什么来优化流程？理想情况下，我想要某种处理多个请求的方式，类似于KeepAlive请求的工作方式。初始化所有模块的所有开销对于读取单个图像或css文件来说都是一种浪费，而对于服务另一个请求来说又是同样的开销

---

有没有办法减少这样一个框架的开销？（我甚至不知道是否有人可以在不研究所有代码的情况下帮助我，这可能是一个无望的问题）

是否有理由为每个请求加载所有模块？为什么不允许控制器指定需要加载的模块，而只加载请求的模块？

为什么不将步骤8移到步骤5之前？首先检查URL，然后根据结果加载模块

另一个：

验证每个模块是否有效且没有语法错误，然后将其包括在内

---

你真的要在

包含（）文件之前检查它们的语法吗？如果是这样，为什么有必要这样做？
通常情况下，绑定一个提供静态内容的动态web服务器线程不是一个好主意。Apache、IIS、Nginx等已经完成了提供这些文件所需的所有工作。如果每个静态资产都位于公共docroot中的某个位置，并且具有唯一的URL，那么您不必担心PHP会参与加载它们

此外，如果您可以确保正确生成与缓存相关的头文件（ETag、Last Modified等），并且每个客户机应该只请求每个文件一次。免费缓存==赢
 语法检查是我想消除的一件事，或者可能是缓存。它们确实是经过语法检查的：首先读入它们并使用返回false对其求值；为了回答您和Dav的问题，必须加载模块来处理请求，因为处理URI的方法是询问每个模块“是否为此URI获取了任何内容？”然后每个模块用该URI的内容以及内容所在页面的部分进行响应。这确实是非常浪费的（两种情况都是如此）。：）您应该将“获取任何内容”信息缓存在某个地方，可以是动态缓存，也可以是为每个模块创建一种“配置文件索引”，这样就可以在不加载整个内容的情况下进行检查。@deceze，是的，我同意，我可能必须重写框架，使模块提供的功能可缓存。请参阅我对deceze的回复：控制器位于模块内部，系统必须加载模块，以便可以轮询每个模块，询问哪些模块具有给定URI的内容。正如deceze在您的回复中所评论的，这是一种非常低效的设置框架的方法。：/至少，您可以考虑配置文件，它指定给定模块可能感兴趣的模式，这样您就可以将模块的轮询减少到至少具有“感兴趣”的远程机会的可能性。或者将另一个PHP缓存工具插入到服务器环境中，以获取纯粹动态的URL。加载和解析所有这些源文件将节省大量文件系统通信量，特别是如果在加载程序中删除语法检查。让web服务器处理静态内容通常在性能方面仍然是一个更大的赢家。不过，我本来打算使用mod_mem_cache，但这把事情搞得一团糟！我在serverfault.com上发布了关于one.APC是另一种缓存的信息——它存储解析PHP源文件而不是其输出所产生的字节码。与基于memcached的页面或片段缓存不同，它不需要显式地将内容标记为可缓存；相反，它只是通过删除每个请求周期中的加载和解析来加速所有PHP。rcoder，对不起，忘了提到我已经在使用eAccelerator，是的，它确实提供了一个很好的提升