我有一个相当简单的Windows服务，它实现了一个C＃TCPIP套接字侦听器服务。该服务是一种专有但简单的协议。即使在重载下，它也能准确可靠地工作。但是，性能不足以达到它必须服务的目的，我一直在努力解决这个问题。
我不知道正式称呼的架构是什么。但它是基本的异步实现（IAsyncResult状态对象，AcceptCallback（），ReadCallback（）等。）。
以下是基本性能问题：作为对请求的响应的一部分，服务必须呼叫远程服务（由某个独立服务提供商运营）。通常，对此操作的响应大约需要一秒钟。但是，如果我加载了20个测试客户端（从多台计算机作为独立使用者运行），则远程服务的一秒响应会延长到5秒或更长时间。我已经使用跟踪来确认所有这五秒钟都在进行那些远程事务的代码中＃34;。跟踪还确认服务器正在按预期同时处理其请求，而不是将它们堆叠起来。
也就是说，我已经完成了独立测试，证明远程服务可以在一秒钟内轻松处理其内容，无论负载如何（该服务由知名公司运营的大型知名公司运营，是为无数组织做的 - 我相信这不是他们的问题。我已经改变了我的负载测试以直接执行此I / O而不是使用该服务，它实现了一秒钟的周转。
最后，作为测试，我在我的服务中实现了多个侦听器，这些侦听器侦听不同的端口并让我的负载测试器客户端在端口之间分配他们的请求。这样做可以提高与端口数量相关的性能（两个监听器==约2X性能）
现在，我知道收听多个端口并不是正确的解决方案，不应该有所作为。但这确实告诉我，我的实现中存在一些缺陷，即干扰了回收侦听器的能力。或者，它表明远程服务的驱动程序正在缺乏周期而且不能方便地响应（尽管我倾向于不相信这种情况）。
吞吐量要求对我来说似乎不高 - 我们每秒只需要处理两个传入请求。我们只需要能够在大约两秒左右的时间内做出响应。但是，五到七秒的回复实际上会降低我们的消费者（这本身就是奇怪的，但我们无法控制它）。
我将Listener.MaxConnections设置为2500.但是，将此数字设置为5000或20并不会影响此问题。
我希望就如何解决这个问题提出一些建议。我怀疑我在错误的上下文中执行一些业务层代码。但是我没有看到它。
此致