0

我一直在研究 OPcache 与 Joomla 的最佳使用。

这个 github 页面，The Zend Engine and OPcode caching，是我见过的关于 OPcache 工作原理的最佳解释，并试图在这里得到几个问题的答案。

解析的文件名：

  • “已解析的文件名”是什么意思？
  • 自从我使用 Joomla 以来，Opache 使用什么作为“已解析的文件名”！CMS 我知道它总是调用 index.php 但传递不同的参数是解析的文件名 index.php?[querystring]

使用的时间戳：

  • “时间戳”如何适用于 Joomla 等 CMS/框架系统！因为由于 index.php 文件永远不会改变，所以在我看来缓存永远不会刷新。

Joomla！CMS缓存系统：

  • 在 Joomla 中使用缓存是否有意义？它将它构建的页面作为php文件写入名为“cache”的文件夹中的文件系统，这些php页面将被调用，而不是Joomla每次都重建页面
4

1 回答 1

1

解析的文件名

解析文件名的 PHP 等效项由realpath()函数获得。如果相对文件名返回规范化的绝对​​路径名，这会将所有符号链接、对输入路径中的“/./”、“/../”和额外的“/”字符的任何引用与当前工作目录进行转换。换句话说，解析的文件名是一个完整的文件名映射到底层文件系统。由于硬链接等原因，它不一定是唯一的。

OPcache使用解析的文件名作为其内部编译脚本数据库的索引，原因有两个：

  • 拥有相关文件名和嵌入式符号链接会打开各种安全和简单的应用程序编程陷阱，这些陷阱可能会导致错误或启用可利用的漏洞。通过使用每个脚本的解析文件名作为其键，OPcache 避免了这些问题。

  • 这也可以通过安装多个软件包（如 phpBB、WordPress、MediaWiki（我假设为 Joomla））来获得实质性的性能优势，这些软件包通常使用分层 PHP 目录结构。您可以将一个公共子目录的多个版本符号链接到一个共享库文件夹，这样一个包的单独逻辑实例可以共享 OPcache 内部数据库中的相同编译脚本。

查询参数与正在执行的脚本完全不同。参数通常因请求而异，具体取决于请求上下文，但执行的脚本是相同的，对于相同处理路径的任何包含的脚本也是如此。

脚本时间戳

OPcache 使用每个底层脚本文件的时间戳作为辅助键。这是为了能够检测到通常会导致时间戳更改的底层脚本的更改。有各种opcache INI 参数可用于降低性能损失，以及 OPcache API 调用（例如opcache_invalidate()）可以使系统管理员显式执行此操作。

由于（标准）OPcache 内部缓存完全在内存中，因此它在文件系统上没有持久版本。因此，每次重新加载底层 PHP 进程层次结构（通常是特定于 Web 服务器）时，都必须重新构建它。是的，这确实会在重新启动缓存时导致启动性能下降。

时间戳的这种使用与脚本编译的缓存有关，并且与任何与应用程序内容相关的缓存完全不同

应用缓存

OPcache 所做的是避免每个请求的编译成本。对于任何基于框架或复杂包（如 Joomla 或 MediaWiki）的 PHP 应用程序，这通常可以占每个请求 CPU 成本的 50-90%，因此可以提高 2-10 倍的吞吐量。

应用程序缓存是特定于应用程序的，并且与避免重复处理应用程序数据的执行应用程序代码的每个请求成本有关。

这些是完全独立的，并且为了获得良好的应用程序性能，您始终应该考虑同时进行。

于 2014-01-31T15:35:46.660 回答