C# WCF中的Keep Alive是否比轮询使用更多的资源？

我可能会设置一些测试床应用程序并找到答案，但我希望有人已经体验过这一点，或者只是有一个更直观的理解。我有三个可执行文件。两个不同的客户端（分别称为Client1.exe和Client2.exe）和一个WCF服务主机（称为host.exe），该主机为这两个客户端承载或多或少的消息总线类型服务。我不会进入“为什么”这个话题，因为这是一个很长的故事，对这个问题没有任何意义

关键是，Client1通过此服务向Client2发送请求。Client2执行操作，然后将结果响应到Client1。Client1将始终是请求的发起方，因此这种操作顺序将始终以这种方式保持一致。这也意味着Client1可以根据需要打开与此服务通信的通道，而由于回调服务的需要，Client2必须保持其通道的打开。我一开始就试图活下去。然而，这些都是桌面和PC上的三个睡眠事件，或者其他问题（不确定）似乎会干扰它。一旦它超时，一切都必须重新开始，这使它成为一个真正的痛苦。我有一些想法，我可以尝试帮助保持活力的方法，但这提出了一个问题，我没有答案。。。这是对我资源的最佳利用吗

按照我的理解，客户2主要有两种方法

通过大量监控（计时器和连接状态检查）和连接重置代码保持活动状态，因为它可以立即响应请求，因此速度更快。缺点是，在用户保持Client2在桌面上打开的整个过程中，这必须保持活跃，这可能是短而甜，也可能是长而疯狂

定期轮询请求，该请求只允许在检查或处理来自Client1的请求时使用资源。这会更慢，因为轮询请求不是实时的，但会消除任何外部问题，例如断开服务。这也会导致我不得不向服务添加更多状态。它已经是一个PerSession服务，包含一个client2id的可用实例列表，这样Client1就知道它正在与哪个实例通信，但它会添加更多

---

Client2执行许多其他功能，因此在这个过程中仍然需要非常出色的性能，这让我想知道哪一个最有可能消耗资源？轮询方法的资源成本是否更高？或者试图保持活动状态？

您甚至可以将状态保留在内存中吗？这意味着任何进程退出（部署、bug、重启、蓝屏）都会丢失数据。关于成本：空请求几乎不需要任何成本。每个CPU核心每秒大约有10公里。因此轮询成本主要取决于服务器端实现的功能。@usr：“您甚至可以将状态保存在内存中吗？”是的。。。我只是说存储从Client1发送的“请求”，以便Client2在轮询“要完成的作业”时找到它。那么，对于您的“关于成本”声明，您是说如果我定期轮询完成的请求，它几乎不需要任何成本（减去在服务中检查请求时发生的情况）？怎么样？创建、打开和关闭频道不需要花费吗？是的，几乎不需要花费任何费用。1毫秒的CPU时间对你来说花了很多吗？可能不会。你可以使用长轮询。客户进行民意测验。服务器会立即返回所有“事件”。如果没有事件排队，那么它最多会等待20秒等待新事件（出于效率原因异步）。这就是AJAX长轮询的工作原理。每20秒需要一次轮询请求，延迟几乎为零。这是一个进行基准测试的好时机，但我希望它能更快响应，至少能为用户提供“近乎实时”的体验。最好在请求的1s内。这就是为什么我最初开始采用“保持活力”的方法，结果却发现尝试这样做会带来一系列挑战。也许投票太快会使核心太多。我没有想到。。。