I was just wondering that separating header, navigation, layout, sidebar, footer into apart pages and with php include function managing them just to be able to reduce time of work is bad approach? Bad influence on performance?
问问题
563 次
5 回答
3
这将对整体页面加载性能产生如此小的影响（如果有的话），以至于在您可能每分钟服务数百万个请求之前不值得考虑，此时您可能已经切换到编译语言。
除非您只是在做一些愚蠢的事情，例如将代码分解成数千个需要加载的可包含文件，否则这绝不应该成为 PHP 中的决定性设计因素。
做使您的代码更易于维护的事情。
于 2013-07-18T19:57:10.900 回答
0
不，它总是额外的文件打开操作，但如果它只是分开的页眉/页脚/侧边栏 - 你真的没什么好担心的；）
于 2013-07-18T19:56:18.957 回答
0
包含页面的处理器负载/时间非常小，以至于您不会注意到它。它甚至没有在我的机器上注册——它是一个单核 CPU，而不是一个花哨的 Web 服务器。
于 2013-07-18T19:56:29.393 回答
0
包含一个文件肯定会影响性能*，但与开发和维护模块化代码所节省的时间相比，它会非常小而且微不足道。
* 如果您包含数以千计的文件，性能会受到明显影响。如果您包含一些文件，则它所花费的额外 CPU/IO 周期不会很明显。
于 2013-07-18T19:57:09.017 回答
0
当然，这种包含的命中性能并不那么重要，但请注意不要包含太多脚本，因为制作 I/O 总是有成本的。
您可以使用APC之类的缓存来确保代码不会对很多 I/O 造成影响。
在这种情况下，您不必担心，但是当您编写更复杂的代码时，我相信您会 :) 您会发现它是我希望的好建议。
看看 apache 服务器上的 thi bench。
当你调用一个简单的echo "hello world";
Total transferred: 3470000 bytes
HTML transferred: 120000 bytes
Requests per second: 2395.73 [#/sec] (mean)
Time per request: 4.174 [ms] (mean)
Time per request: 0.417 [ms] (mean, across all concurrent requests)
Transfer rate: 811.67 [Kbytes/sec] received
因此，即使查询很简单，也要始终考虑性能损失，因为 PHP 做了很多事情来打印数据。
于 2013-07-18T20:01:36.137 回答