与Joomla的Opcache！和已解决的名称

Question

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

这个github页面The Zend Engine and OPcode caching是OPcache如何工作的最佳解释，我已经看到并试图在这里得到几点答案。

已解析的文件名：

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

使用的时间戳：

• “时间戳”如何应用于诸如Joomla之类的CMS / Framework系统！因为index.php文件永远不会改变，所以在我看来缓存永远不会刷新。

的Joomla！ CMS缓存系统：

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

Answer 1

已解决的文件名

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

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

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

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

查询参数与正在执行的脚本完全不同。根据请求上下文，参数通常因请求而异，但执行的脚本是相同的，并且同一处理路径中的任何包含脚本都是相同的。

脚本时间戳

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

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

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

应用程序缓存

OPcache所做的是避免每次请求编译成本。对于任何基于框架或复杂软件包（如Joomla或MediaWiki）的PHP应用程序，这通常可代表每个请求CPU成本的50-90％，从而使吞吐量提高2-10倍。

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

这些是完全独立的，为了获得良好的应用程序性能，您始终应该考虑两者兼顾。