我有一个asp.net mvc4 web api界面，每天可以获得大约54,000个请求。
http://myserv.x.com/api/123/getstuff?whatstuff=thisstuff
我在负载均衡器后面有3个Web服务器，用于处理http请求。
平均响应时间约为300毫秒。然而，最近出现了一些错误（或者可能一直存在），因为在10-20秒内会出现零星的响应时间。这将是针对直接命中同一服务器而不是通过负载均衡器的相同请求。
GIVEN:
- System has been passed down to me so there may be gaps with IIS confiuration, etc,.
- Database: SQL Server 2008R2
- Web Servers: Windows Server 2008R2 Enterprise SP1
- IIS 7.5
- Using MemoryCache aggressively with Model and Business Objects with eviction set to 2hrs
- Looked at the logs but really don't see anything significantly relevant
- One application pool...no other LOB applications running on this server
假设＆amp;问： 不知何故，我认为某些东西正在回收应用程序池，或者IIS工作线程正在关闭并重新启动，从而导致每个新请求进行预热和重新缓存。这是零星的，现在很难解决问题。对同一服务器的相同请求按预期快速返回（背靠背N个请求），因为它在大约300毫秒内缓存....但是等待大约5-10-20分钟，同一个服务器的相同请求需要16秒。 / p>
由于这些是prod系统，因此我的跟踪数量有限，因此我只能公开如此多的日志记录详细信息。任何帮助和信息攻击其他人遇到的这种或类似的行为表示赞赏。 THX
更新 w3wpe.exe进程增长到~3G。它会以某种方式被消灭，PID会自行改变，或者每3-4分钟就会发生一次，我在网络服务器（IIS）日志中看到了大量的警告：
为应用程序池'MyApplication'提供服务的流程遭遇致命 Windows进程激活服务的通信错误。该 进程ID是'1732'。数据字段包含错误编号。
答案 0 :(得分：4)
在评估IIS和配置与内部代码问题4-5天后，我终于发现了这个问题，对windbg或debugdiag IIS工具几乎没有帮助。这些工具包含很多信息，即使是迷你转储或日志跟踪堆栈，它们也可以是红色鲱鱼。最好的办法是通过设置一个生产系统的“智能复制”实例来重现它，这是我们当时没有的，并且需要一些操作来设置。
毋庸置疑，问题与过度缓存业务对象有关。有一种竞争条件，某个表上的更新正在更新相应业务对象的属性（更新来自多个服务器），这导致OOC堆栈溢出，这几乎导致缓存以递归方式缓存自身死亡，从而导致w3wp .exe进程死亡和伪造回收本身。这是在非生产环境中难以测试和重新编写的边缘案例之一。