Zend MVC 应用程序的所有区域出现间歇性错误“文件不存在：/var/www/html/var”，导致页面偶尔无法加载 - 而通常它们可以完美加载。
我们的设置
AWS 上 LAMP 堆栈上的 MVC 应用程序具有：
- 中型 c1 AWS linux AMI 64 位实例上的 Zend 1 前端应用程序
- 中型 m1 AWS linux AMI 64 位实例上的 MySQL 数据库
- 在应用服务器上与 MVC 应用并行运行 phpbb3 论坛，数据库服务器上有 2 个数据库（一个用于应用程序，一个用于 phpbb）
- php 5.4.22
- mysql 5.1.72 + mysqli
- 与应用程序和数据库服务器关联的弹性 IP 地址
- 应用程序和数据库服务器使用私有 IP 连接（即应用程序服务器连接到数据库服务器私有 IP，数据库服务器安全组在端口 3306 上接受应用程序服务器私有 IP）
- 当前将站点作为开发站点运行，使用主站点外的开发目录，例如：
www.mysite.com/dev/
在 /dev/configs/application.ini 中我们定义以下内容：
setting.basedir = dev setting.baseurl = http://www.mysite.com/dev setting.securebaseurl = http://www.mysite.com/dev我们的 DNS 使用的是 godaddy，并且使用 A 主机 = IP 地址（即 IP.IP.IP.IP）而不是 cname，
- 没有使用虚拟主机（因为每个“服务器”只有一个站点）
- 我们有 htaccess 文件和各种重定向 - 但在我们的本地 LAMP 服务器上没有错误
- 我们正在使用 minify 并注释掉 RewriteBase（默认）
httpd.conf 设置大部分都是默认的（如果有重要的设置没有列在这里，请告诉我）
ServerName www.mysite.com UseCanonicalName Off DocumentRoot "/var/www/html" <Directory /> Options FollowSymLinks AllowOverride ALL </Directory> <Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory>
问题
我们在 /etc/httpd/logs/error_log 中收到以下间歇性错误：
文件不存在：/var/www/html/var，引用者： http://www.mysite.com/dev/various
发生此错误时，我们尝试访问的网站部分的半完整页面都会显示以下消息：
“无法将元数据保存到 metadataCache”
错误是间歇性的，因为我们无法通过任何动作序列或时间重复它：
- 反复刷新页面似乎可以解决这个问题，页面最终将正确显示，网站的其余部分可以在较长时间内正常访问
- 它与浏览器或 IP 地址（用于访问网站）无关
- 它似乎与我们尝试访问的页面无关（即我们在所有网站页面上都遇到了错误）
- 在网站闲置一段时间后再访问网站的新部分时，错误似乎会重新出现 - 尽管这是不一致的（有时错误会在积极使用网站的过程中再次出现）。
我们在本地机器上没有遇到这个问题 - 我们的开发人员在 Mac Lamp 堆栈和 Windows 机器上拥有大约 3 台不同的本地机器。
我们在原始 AWS 配置上没有遇到问题，该配置是单个 Linux ami 微实例上的应用程序 + 数据库 - 通过 ec2 地址和 configs/application.ini baseurl 设置为 ec2 地址进行访问（即我们在那个阶段没有使用 DNS A 主机设置）
我们尝试过的理论和方法：
当我们更新 application.ini 设置以使用 IP 而不是 DN 时，我们似乎没有收到错误（这表明存在某种服务器根/dns 循环）
setting.basedir = dev setting.baseurl = http://www.IP.IP.IP.IP.com/dev setting.securebaseurl = http://www.IP.IP.IP.IP.com/dev最初我们认为可能是 httpd.conf 中的 ServerName 被注释掉了，但当我们将其设置为 www.mysite.com、mysite.com 或“www.mysite.com”时，没有任何区别
- 我们已经完成了删除所有 Zend + 论坛 + 浏览器缓存、重新启动 Apache、重新启动 MySQL 等常规步骤
我们所做的一切似乎都无法表明错误的根源在哪里。