我有一个通过wfastcgi
配置部署到 IIS 的 Flask 站点。
当我使用 chrome 或 firefox 开发者工具分析主页的加载时间时,我发现很多秒(平均从 6 到 10 秒)作为接收第一个字节的等待时间。
甚至是 30 秒之前,但后来我“优化”了我的 python 代码,以避免在加载时进行任何 db sql 操作。然后我按照这个nspointers 博客的提示,现在从服务器的任务栏中,我看到了w3wp.exe
我的应用程序池标识
w3wp.exe – 它是应用程序池的 IIS 工作进程
即使在空闲时间也能保持正常运行。但这对其他人来说是不正确的
python.exe – Django 或烧瓶应用程序的主要 FastCGI 进程。
而且我不确定这是否是一个问题,以防万一我应该做什么,除了提到的帖子中描述的第 4 步。
现在在“进程模型”下的“编辑 FastCGI 应用程序”对话框中,编辑“空闲超时”并将其设置为 2592000,这是该字段的最大值(以秒为单位)
我还查看了 Flask 应用程序编写的日志,并将其与 IIS 编写的日志进行了比较,这是让我相信问题出在执行 python 代码之前wfastcgi
的部分的最重要的一点。
因为我看到time-taken
IIS 日志的时间与 chrome 或 firefox 报告的客户端时间匹配,TTFB
并且 python 在执行开始时写入的日志几乎与 IIS 写入的时间同时记录,即
对应于请求完成的时间
(正如我所想的那样,我发现这个答案已经证实了这一点)
所以总而言之,根据我的尝试和我的理解,我怀疑 IIS在实际开始执行我的应用程序代码以产生对 Web 请求的响应之前“浪费”了很多秒来“准备”python命令。wfascgi
在我看来真的太多了,因为我在 IIS 下开发的其他应用程序(例如在 F# WebSharper 中)没有这种wfastcgi
立即在浏览器中加载的机制,而且它们与 python Flask 应用程序之间的响应时间差异很大显。我还能做些什么来改善响应时间吗?