我有一个托管在IIS 6.0上的WCF服务(内置于.NET framework 3.5)。
代码流程如下
我正在加载测试我的WCF服务以定义阈值。观察结果如下:
在1分钟内向WCF服务发出的1024次请求大约3次迭代成功通过。完成每次迭代所需的时间约为25-30分钟。 但是从第4次迭代可以看到批量故障。大约50%的请求因以下异常而失败。
异常 - 线程正在中止。
堆栈跟踪
21_10_2016_09_30_52,9:30:52 AM,Information,Thread name- apSwTTbLTETfwT3y Stack trace in ProcessTestConversion method - at System.Threading.WaitHandle.WaitOneNative(SafeHandle waitableSafeHandle, UInt32 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.InternalWaitOne(SafeHandle waitableSafeHandle, Int64 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean exitContext)
at System.Net.LazyAsyncResult.WaitForCompletion(Boolean snap)
at System.Net.Connection.SubmitRequest(HttpWebRequest request, Boolean forcedsubmit)
at System.Net.ServicePoint.SubmitRequest(HttpWebRequest request, String connName)
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
.
.(My function calls stack trace)
.
.
我试图解决这些问题的变化如下:
<behavior>
<serviceThrottling maxConcurrentCalls="2000"
maxConcurrentInstances ="2400"
maxConcurrentSessions ="400"/>
</behavior>
web.config中的
<system.web>
<compilation debug="false" />
<httpRuntime executionTimeout="1800"/>
</system.web>
web.config中的
<system.net>
<connectionManagement>
<add address = "*" maxconnection = "100" />
</connectionManagement>
</system.net>
web.config中的
ServicePointManager.DefaultConnectionLimit = 100; (Change in code)
我已按照StackOverflow上的许多人的建议将App池的IdleTimeout属性设置为0。
无论在哪里使用溪流,我都会在所有地方进行处理。所以所有的流都关闭了。
任何人都可以告诉我谁在中止线程以及为什么有任何方法或工具来跟踪线程中止启动的原因?
答案 0 :(得分:3)
我遇到过这个问题,这是由于客户端类的使用不当。
当发生客户端类实例化时,它不会释放资源导致吞吐量降低。将发生一个非常无益的异常“线程被中止”。这是通过创建一个辅助类来解决的,泛型已经创建了一个客户端对象,然后正确地实现了构造函数和dispose方法。
某些IIS异常对问题的实际原因不是很有帮助或真实,但要了解解决我的问题所做的工作是查看IIS日志。特别是“Failed Request Tracing Rules”
希望这会有所帮助,我能理解你的挫败感,这是一个令人头疼的问题。
答案 1 :(得分:2)
存在问题,因为在使用类型化客户端时自动清理资源的C#using
语句不成功,并且任何抛出的异常都会被隐式dispose屏蔽掉,这会占用实际异常&amp;抛出一些其他异常,如超时或其他异常。
C#“using”语句导致调用Dispose()。这与Close()相同,它可能在发生网络错误时抛出异常。因为对Dispose()的调用隐式发生在“using”块的右括号中,所以这个异常源可能会被编写代码和读取代码的人忽视。这代表了应用程序错误的潜在来源。 (来自MSDN)
你应该释放资源,如:
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}
通过这种方式,您不仅可以找到实际的异常来源。当一些执行发生时也释放资源。
其他替代解决方案可以实现Dispose
,例如:
/// <summary>
/// Calculator Client
/// </summary>
public partial class CalculatorClient : IDisposable
{
#region IDisposable implementation
/// <summary>
/// IDisposable.Dispose implementation, calls Dispose(true).
/// </summary>
void IDisposable.Dispose()
{
Dispose(true);
}
/// <summary>
/// Dispose worker method. Handles graceful shutdown of the
/// client even if it is an faulted state.
/// </summary>
/// <param name="disposing">Are we disposing (alternative
/// is to be finalizing)</param>
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
try
{
if (State != CommunicationState.Faulted)
{
Close();
}
}
finally
{
if (State != CommunicationState.Closed)
{
Abort();
}
}
}
}
/// <summary>
/// Finalizer.
/// </summary>
CalculatorClient()
{
Dispose(false);
}
#endregion
}
来源: