我有一个很好的快速任务调度组件（Windows服务，因为它发生但这是无关紧要的），它订阅了一个内存队列的事情要做。
队列的填充速度非常快......当我说速度快的时候，我的意思是快速......这么快，以至于我遇到了某个特定部分的问题。
队列中的每个项目都附加一个“类别”，然后传递给WCf端点进行处理，然后保存在远程数据库中。
这提出了一些问题。
“队列”可以每分钟处理数百万个项目，而WCF端点只能实际处理每秒大约1000到1200个项目，其中许多项目是“堆叠”的，以便等待一个插槽转储它们到db。
我的WCF客户端已经过配置，因此呼叫是开火并且忘记（故意）我的问题是，当有时发生超时时会发生超时，并且当头痛开始时。
线程似乎在超时之后停止没有任何下降到我的catch块没有...只是坐在那里，更令人困惑的是这是一个间歇性的事情，这只发生在队列处理极端负载和WCF端点过度征税，即使在那种情况下，这也只是大约两周一次。
此代码在服务器上不断运行，全天候24小时。
所以......我的问题...... 如何识别导致我的问题的边缘情况，以便我可以解决它？
一些额外信息：
调用WCF端点的客户端似乎自动“限制自己”因为我限制了调用的线程数，并且代码一直持续到调用被认为完成（我认为这是一个http级别的事情因为我没有向服务请求我的方法调用的结果。）
数据库与EF进行通信，它似乎永远不会打开超过固定数量的数据库连接（相当低的数字也很酷），而来自呼叫接收的WCF端点似乎非常可靠。
问题似乎是从队列处理器到WCf端点。
队列处理器有一个我的WCF端点客户端实例，它可以为所有调用重用...（每次调用重建这个端点是一种好习惯吗？ - 请记住这里的调用次数。）
最后的说明：
这是一个特殊的功能“模块”，在一次几小时的重载下它是稳定的，但由于某种原因，这个奇怪的事情发生导致整个停止而不是恢复。该调用包含在try catch中，但看起来即使捕获了（这是不可保证的）代码也没有按预期恢复/退出...它只是挂起。
有什么想法吗？
请告诉我是否还有其他任何内容可以帮我解决此问题。
编辑1：
绑定 - basicHttpBinding
错误处理 - 除了在try catch中包装WCF调用之外，没有编写代码。
答案 0 :(得分：0)
看起来我的解决方案似乎是增加客户端配置的超时设置，以便让服务器有更多的时间来响应。
最终结果是，当数据库忙于保存数据时（实际上是此过程中最慢的部分），调用客户端坐下并等待（在所有线程上，但似乎没有我想要的那么长）。
这个问题似乎是许多对WCF的多线程调用的最终结果，并没有给它足够的时间来响应。
高负载并不是一成不变的，服务使用似乎是尖峰然后尾部关闭，增加预期的响应时间允许尖峰在发生时进行过滤。
关键说明： 太多的调用会导致服务器/服务将它们视为dos类型攻击，因此可能只是终止连接。 这不是我得到的，但是一些微调和时间可能导致这个......
一些更大的服务器的时间!!!