最近，在使用EventStore的.NET Client API采用大量线程池线程同步写入Event时（用于模拟ASP.NET服务端大并发写入Event的情况），发现EventStore的连接会随机中断，并且在服务端日志中显示客户端连接Heartbeat超时（如果不了解EventStore，请点击传送门）。由于系统中全局共享一个EventStore连接，当连接中断时，会导致所有的写入操作被Block，而EventStore连接的重连速度比较慢（测试机器上重连需要耗费20秒到1分钟），这样会导致比较严重的性能问题、甚至导致客户端请求超时。
示例代码如下：
for( int index=0;index<100;index++)
{
Task.Run( ()=> { connection. AppendToStreamAsync(...).Wait(); } );
}
也许有人会问，为什么不为每一个请求单独建立一个EventStore连接？好吧，绕开官方文档推荐使用单连接这个问题不谈，似乎为每一个请求建立一个连接是一个好的解决方案，但是实际测试发现这个方案比单链接方案更不靠谱。经过测试发现（使用EventStore版本3.0.5.0测试），为每一个请求单独建立连接会有以下几个方面的问题：
1）每次请求都需要重新连接EventStore Server，耗费的时间比较长，性能比单连接差。
2）重复的建立和断开连接会导致EventStore服务端的TCP端口失去响应（大概30K次连接之后），在这种情况下除非重启EventStore Server，否则客户端再也无法连接上EventStore Server。
3）如果一个连接非正常中断，则所有的连接都会断开重连。
由于多连接存在上面的问题（中途也尝试过连接池，发现也同样存在上述问题），我们只能在单连接这个方向上继续前行，我尝试着将上面的代码修改为如下形式，竟然发现问题神奇的消失了。
for( int index=0;index<100;index++)
{
var tempThread = new Thread(()=>{connection. AppendToStreamAsync(...).Wait();});
tempThread.IsBackground = true;
tempThread.Start();
}
这两段代码有什么区别呢？有问题的代码是使用线程池的线程来同步写入Event，而没有问题的代码则使用线程同步写入Event，貌似没有什么区别。会是什么问题呢？我又回过头将第一段代码修改为如下形式（将同步写入修改为异步写入，注意：将Wait方法调用去掉），竟然也发现没有问题。
for( int index=0;index<100;index++)
{
Task.Run( ()=> { connection. AppendToStreamAsync(...); } );
}
那么问题出在什么地方呢？会不会是EventStore本身的问题呢？由于使用HTTP接口来写入Event非常的稳定，可以基本排除是Event Store Server的问题，那么EentStore .Net Client API有问题的可能性就比较大了。
没有办法，从GIT上下载EventStore的源代码开始调试，最终发现了问题可能是下面的代码引起的：
public void EnqueueMessage(Message message)
{
Ensure.NotNull(message, "message"); _messageQueue.Enqueue(message);
if (Interlocked.CompareExchange(ref _isProcessing, 1, 0) == 0)
ThreadPool.QueueUserWorkItem(ProcessQueue);
} private void ProcessQueue(object state)
{
do
{
Message message; while (_messageQueue.TryDequeue(out message))
{
Action<Message> handler;
if (!_handlers.TryGetValue(message.GetType(), out handler))
throw new Exception(string.Format("No handler registered for message {0}", message.GetType().Name));
handler(message);
} Interlocked.Exchange(ref _isProcessing, 0);
} while (_messageQueue.Count > 0 && Interlocked.CompareExchange(ref _isProcessing, 1, 0) == 0);
}
这段代码的目的是将客户端写入的自定义事件或者系统产生的事件(无论客户端写入的自定义事件还是系统事件都会被存储到一个唯一的Queue中)，顺序的发送到服务端。说到这里就必须提一下EventStore TCP连接的心跳机制，当客户端与EventStore服务端建立连接之后，客户端会定期发送一个Heartbeat事件到服务端，通知服务端客户端还活着，如果在一定的时间内，服务端收不到来自客户端的Heartbeat事件，那么服务端会主动关闭连接，并且在日志中记录一条客户端Heartbeat超时日志。
那么这段代码与连接中断有什么关系呢？注意，客户端的Heartbeat事件也是通过这段代码发送到服务端的。如果，我说如果，由于什么原因导致Heartbeat事件不能及时的发送到服务端，会不会导致连接中断呢？答案是肯定的。
那么这段怎么看都没有问题的代码为什么在使用线程池线程并发写入的情况下会导致Heartbeat事件发送不及时呢？是不是这句话有问题？难道在大并发的情况下QueueUserWorkItem会导致ProcessQueue的调用会被延迟？
ThreadPool.QueueUserWorkItem(ProcessQueue);
为了验证我的想法，我创建了一个System.Threading.Thread.Timer，定时100毫秒，在Callback中输出两次Callback之间的时间差，当大量的使用ThreadPool的线程时，发现两次Callback之间的时间差慢慢的从200毫秒，越变越大，直到到好几秒。问题到这里就已经很清楚了，当ThreadPool的线程被大量占用时，通过QueueUserWorkItem注册的回调方法会有一定的延迟，具体的延迟时间与ThreadPool的线程被占用的时间和数量有关系，对于实时性要求比较高的任务，比如EventStore的ProcessQueue来说，是不适合使用QueueUserWorkItem来注册回调的。
最后，我将EventStore代码中的QueueWorkItem调用替换为线程调用，发现问题解决。
后续，为了说明这个问题，我在EventStore的Group中发布了一个帖子说明这个问题，EventStore的作者认为Task.Run不能真实的模拟ASP.NET的情况，建议我到真实环境中测试。为此我创建了一个简单的ASP.NET MVC项目和一个简单的客户端，模拟大压力下两种实现的差别。通过测试发现，使用原版的API，随着并发线程数量的增长，Event的写入速度越来越慢，而使用修改后的API，则发现随着并发线程数量的增长，Event的写入速度变化不明显，基本上没有太大的差别，理论上来说在某一个并发下应该会导致Heartbeat超时。由于IIS默认并发访问数量的限制，又懒得去调整服务器，并且由于IIS本身又管理了一套连接池，想压出Heartbeat超时比较困难，就没有做Heartbeat超时的压力测试。
