我们在IIS 6.0上托管WCF服务的其中一台服务器上观察到以下行为：
> IIS日志显示一个很高的时间值(> 100000)
> HTTP状态码为200
> sc-win32-status代码显示值为64
我发现sc-win32-status code of 64表示“指定的网络不再可用”
最初我怀疑这可能是因为MinFileBytesPerSecond设置的限制，它设置了HTTP.sys在从客户端发送数据到服务器并从服务器返回到客户端时执行的最小吞吐率。
但是，sc-bytes和cs-bytes的值表示发送的数据量在服务一般观察到的范围内。
另请注意，WCF服务托管在四个框上，并且是负载平衡的，但问题只发生在其中一个服务器上。 (但本质上不在同一台服务器上)。这个问题也是间歇性的。
有没有人遇到这个错误？关于什么可能是错的线索？
更新
注意：观察IIS 7.5(IIS版本并不重要)
我能够复制这个问题。如果出现以下问题：
WCF服务需要很长时间才能回应
2.客户端代理在从服务器收到响应之前超时。在这种情况下，它会导致客户端上的TimeoutException。
3.服务器持续等待客户端的TCP ACK，它永远不会收到。
因此长时间超时(TCP套接字超时(默认值：4分钟)和sc-win32-status为64
所以基本上看起来，WCF代码需要很长时间来响应，客户端超时，我在IIS日志中观察到的只是一个症状，而不是一个问题。
IIS将服务置于睡眠状态以节省资源。
从这里复制(WCF REST Service goes to sleep after inactivity)
The application pool hosting your service defines Idle Time-out property (advanced settings of app pool in IIS management console) which defaults to 20 minutes. If no request is received by the app pool within idle timeout the worker processes serving the pool is terminated. After receiving a new request the IIS must start the process again,the process must load application domain and all related assemblies,compile .svc file,run the service host and process the request.The solution can be increasing idle time-out but the meaning of this time-out is correct handling of server resources. If the process is not needed it should be stopped. Another ugly workaround is using some ping process (for example cron job or scheduled task on the server) which will regularly ping call some method on the service or page in the same application.
