我希望使用IIS应用程序请求路由作为反向代理缓存。我看了几个不同的选择,得出的结论是它最适合我的需求。
然而,我遇到了一个死胡同,我真的可以从对ARR模块有更多经验的人那里得到一些输入。
我有以下设置:
-
IIS ARR缓存对内部服务器场的代理请求(加权
使用最近的源服务器的循环负载平衡)。
-
在IIS代理中禁用了保持活动。
-
服务器场由nginx Web服务器组成。
-
IIS服务器具有RAM磁盘缓存。
用例是这样的,边缘服务器将接收字节范围请求,当它将内容提供给最终用户时,它将对其进行缓存(首先在内存缓存中缓存60秒,然后将其写入RAM磁盘)。到目前为止,一切都正常工作,但当下一个最终用户开始请求相同的字节范围(现在在缓存中)时,我开始了,所以看到IIS边缘和nginx起源之间的一些奇怪行为:
根据第一个字节范围请求(由第二个最终用户),IIS服务器打开一个到nginx源的连接,但它不使用该连接,因为它在缓存中已经有了请求的段。由于连接没有被使用,它最终被nginx关闭,原因是超时(60秒)。与此同时,第二最终用户仍在请求高速缓存中的文件段。然后,这就是问题发生的地方,第二个最终用户到达文件中不在缓存中的一个点。我期望IIS在这里的行为(即禁用保持活动)是,它将打开与源的新连接,并开始获取文件中不在缓存中的部分。然而,我看到的行为是,IIS试图重用它在请求开始时打开的同一连接(而没有意识到它已经被源删除)。我也使用了“失败的请求跟踪”来验证这一点,结果是IIS没有从源获得预期的回复(因为连接不再存在),然后又向最终用户返回502.3。
我已经验证了增加源端的连接超时将“解决”问题,但这并不是一个真正可行的解决方案,因为我基本上必须设置无限超时,这可能会在源端引发一系列新的问题。是否有任何方法可以控制IIS如何处理此上游连接(即,当它实际需要来自源的数据时,强制它打开一个新连接,或者让它意识到源关闭了连接)?
