php适合cpu密集型还是io,嵌套PHP是否包含CPU /内存密集型？

PHP开销

答案是将应用程序逻辑分解为源层次结构取决于您的解决方案的托管方式.

>如果您使用专用主机/ VM,那么您可能会有mod_php Xcache或者等效,答案将是：不,它并没有真正触及运行时,因为所有内容都在PHP Opcode级别内存缓存.

>如果您使用共享托管服务,那么它将影响性能,因为任何PHP脚本都可能通过PHP-cgi加载,可能是通过suPHP,并且需要读入和编译包含的整个源层次结构.更糟糕的是,在共享解决方案中,如果此请求是第一个,例如1分钟,则服务器文件缓存将被刷新,并且编组此源将涉及大量物理I / O =秒时间延迟.

我管理了一些phpBB论坛,并发现通过聚合共享托管实现的常见包含层次结构,我可以将用户响应时间缩短一半.这里有一些文章更详细地描述了这一点(Terry Ellison [phpBB]).并引用一篇文章：

Let me quantify my views with some ballpark figures. I need to emphasise that the figures below are indicative. I have included the benchmarks as attachments to this article, just in case you want to validate them on your own service.

20–40. The number of files that you can open and read per second, if the file system cache is not primed.

1,500–2,500. The number of files that you can open and read per second, if the file system cache is primed with their contents.

300,000–400,000. The number of lines per second that the PHP interpreter can compile.

20,000,000. The number of PHP instructions per second that the PHP interpreter can interpret.

500-1,000. The number of MySQL statements per second that the PHP interpreter can call, if the database cache is primed with your table contents.

MySQL连接

这里最简单的方法是连接池.我使用自己的mysqli类扩展,它使用标准的单对象每类模板.在我的情况下,任何模块都可以发出：

$db = AppDB::get();

返回此对象.这很便宜,因为它是一个涉及六个PHP操作码的内部调用.

另一种传统的方法是使用全局来保存对象并且只做一个

global $db;

在任何需要使用它的函数中.

小型应用的脚注

您建议将所有包含组合到单个包含文件中.这对于稳定生产来说是可以的,但在测试期间会很痛苦.我可以建议一个简单的妥协吗？将它们分开进行测试,但允许加载单个复合材料.您可以分为两部分(i)我假设每个include都定义了一个函数或类,因此对每个包含使用标准模板,例如：

if( !function_exists( 'fred' ) ) {

require "include/module1.php";

}

在主脚本中的任何加载简单之前：

@include "include/_all_modules.php";

这样,当您测试时,删除_all_modules.php并且脚本将回退到加载单个模块.如果您满意,可以重新创建_all_modules.php.你可以通过一个简单的“发布”脚本来执行此服务器端事务

system( 'cp include/[a-z]*.php include/_all_modules.php' );

这样,您就可以获得两全其美的效果