空php文件的第一个字节值存在很长时间

几个月前我有过这样的经历。现在为了解决这个问题，我尝试了一种新的方法。我把一个空文件放到服务器上

文件名为“foobar.php”。其内容如下：

<?php
echo "hello world";

hello world<br/>

---

显然是一个PHP问题，因为Apache在服务静态文件方面没有问题。你试过从PECL安装吗

使用像APD这样的PHP探查器将向您显示瓶颈是否在PHP中，如果是，它在哪里。例如，您正在使用的框架是否缓慢？或者只是一个恶意的扩展

官方的解释是：

使用APD，您只需在入口点添加一条指令：

<?php
apd_set_pprof_trace();
?>

如果配置文件中没有显示任何延迟，则表明这是系统范围的PHP配置问题（可能是恶意或错误配置的扩展）。但是我猜它是框架中的某个东西。
如果同一个空PHP文件在移动到另一个站点时立即加载，那么它不可能是由于任何框架或包含的文件，因为此时未加载任何文件

这可能是php或Apache端的配置问题，也可能是由重写规则引起的。我建议尝试以下方法：

1.）如果允许每个站点的PHP设置，请托管公司将您的特定PHP.ini重命名为其他名称，从另一个站点复制PHP.ini并重新启动Apache，看看这是否有帮助。我在Windows上遇到了类似的问题，这是由于php.ini上的文件访问问题造成的，所以这可能会有所帮助

2.）暂时重命名.htaccess并再次访问php文件。如果加载时间减少，则会出现错误重写条件或其他指令。您是否也可以发布.htaccess的内容？
如果没有提供商的合作，您就没有机会发现问题所在

我认为这是类似于会话的磁盘io问题

另一个有趣的点是，您的提供商使用：
从没听说过那个贝弗尔

如果您的供应商愿意按照mjk的建议行事，您只需更换供应商即可。
很可能是他们没有控制住自己。
您写道，当这个问题发生时，您有几个客户端每3秒执行一次AJAX请求。这使得服务器上所有可用的PHP工作人员都可能被这些AJAX请求阻止。您的web服务器接收到您对
/foobar.php
的请求，然后必须等待php工作人员自由处理您的请求

因此，针对您的问题的可能解决方案包括（如果您没有更具体地说明AJAX的用途，那么我需要保持这一通用性）：


让AJAX请求转到静态文件
确保PHP在（AJAX）请求完成时真正关闭连接，例如使用
头（“connection:close”）（尽管这可能还不够，但请查看

减少AJAX请求的数量（与提供商合作确定的数量）

通常，您需要提供商的帮助来解决此问题。您没有编写提供程序用于服务PHP的方法，例如，在fpm中有一个名为
process.max
的设置，它会限制您的web服务器并行处理如此多的PHP文件的能力。
您可能想看看xdebug profiler，给你一个很好的视觉概述，其中的一部分采取time@MichelFeldheim在我的本地计算机上运行xDebug会给出一个意见吗？因为我的托管公司不允许我使用xDebug。是的，在本地计算机上运行xDebug足以确定时间消耗者。put
print\r（get\u included\u files（））
在“空”php文件中—如果您实际上没有加载空文件—它将告诉您先加载了哪些文件。如果你没有<代码> App/WebOOT/<代码>作为你的域的DOC根-你必须考虑你添加的任何MODY重写规则。@ AD76我写下了这个结果：数组（[0）= /VAR/WWW/VSTOS/Excel。COM/HTTPDOS/APP/WebOOT/FoBABAR.PHP）看起来好像“PHPYAPD.SO”没有加载到托管公司的配置中。我编辑了问题并添加了扩展列表。
似乎显然是一个PHP问题
-令人失望的是，这个答案从一个明显的错误陈述开始就获得了奖金。问题也可能在Apache中，依赖于响应。。。现在有同样的问题，php脚本运行0.2秒，但响应需要0.65秒。静态内容在0.02秒内重新运行。感谢您的回复。我听不懂最后一句话。您的意思是，如果提供者不给予许可，您需要对服务器进行root访问，才能执行用户MJK（我上面的帖子）告诉您的操作。但是一个碎片主人会同意你的。但你可以要求这样做。但是，如果他们没有链接到调试你的问题，只给你一个简单的答案，cpu只是空闲的。我建议您更换提供商。对于MJK的解决方案，提供商会选择什么？我应该告诉他们怎么做？他们应该显示“apd.so”目录，设置“dump directory path”并重新启动Apache？这就是您的方式。但因为你为他们的服务付钱。我只会将hello_world.php放在服务器上，并告诉提供商，加载时间超过0.01秒是不可接受的1。）提供商需要编译此文件。你不知道他在干什么。2.）您的提供商需要调试此问题。我将尝试的是：在cli上运行脚本，以测试时间。运行per或其他cgi脚本以测试performancen。当per也有这个问题时，这是apache/Webserver的问题。如果没有，则可以使用APD跟踪问题。3.）我仍然怀疑舒尔的磁盘io存在问题。此外，我将尝试禁用会话自动启动和apache日志记录以进行测试。如果其中一个改进了性能，那么您的提供商可以在单个主机上mutch主机删除一个htaccess文件并不是问题的原因
bash-2.05b$ pprofp -R /tmp/pprof.22141.0

Trace for /home/dan/testapd.php
Total Elapsed Time = 0.00
Total System Time  = 0.00
Total User Time    = 0.00


Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
100.0 0.00 0.00  0.00 0.00  0.00 0.00     1  0.0000   0.0009            0 main
56.9 0.00 0.00  0.00 0.00  0.00 0.00     1  0.0005   0.0005            0 apd_set_pprof_trace
28.0 0.00 0.00  0.00 0.00  0.00 0.00    10  0.0000   0.0000            0 preg_replace
14.3 0.00 0.00  0.00 0.00  0.00 0.00    10  0.0000   0.0000            0 str_replace