ajax - 使用 ajax 和 web api 进行长轮询有什么问题……它会杀死我的服务器吗？和字符串比较

Question

我有一个非常简单的长轮询 ajax 调用，如下所示:

(function poll(){
    $.ajax({ url: "myserver", success: function(data){
        //do my stuff here

    }, dataType: "json", complete: poll, timeout: 30000 });
})();

我今天下午刚拿起这个例子，它似乎工作得很好。我正在使用它在我的页面上构建一些 html，据我所知，它几乎是即时的。我有点担心这会使我的服务器上的工作线程保持打开状态，并且如果服务器上的负载太大，它将完全停止。有人可以解释一下这个理论吗？在后端，我有一个 webapi 服务 (.net mvc 4)，它调用数据库，构建对象，然后将对象传回。在我看来，为了让这个工作，服务器必须不断地调用数据库......这不太好对吧？？？

我的下一个问题是客户端确定是否需要更新页面上的 html 的最佳方法是什么？目前我正在使用 JSON.stringify() 将我的对象转换为一个字符串并将归结为旧字符串的字符串进行比较，如果有增量，它会重新编写页面上的 html。现在没有一个整体很多对象都在下降，但它可能会变得非常大，我认为在客户端上进行字符串比较可能会占用大量资源......特别是如果它几乎不断地进行。

对我来说最重要的是:我不确定轮询的工作时间。我只是在谷歌上搜索并找到了上面的示例代码并实现了它，从表面上看，它很棒。我只是担心它会陷入困境下来(在服务器上)，我将旧结果与新结果进行比较的方式将陷入困境(在客户端上)。

非常感谢您提供的任何和所有信息。

TIA。

Answer 1

好的，我的两分钱:

正如其他人所说，SignalR 是经过尝试和测试的代码，所以我真的会考虑使用它而不是编写自己的代码。

SignalR 确实更改了一些 IIS 设置以针对此类工作优化 IIS。因此，如果您想实现自己的，请查看 IIS setting changes done in SignalR

我想您正在进行长轮询，以便您的服务器可以实现某种形式的服务器推送。请记住，这将 将您的无状态 HTTP 机器变成有状态机器 如果你想扩展，这不好。负载均衡器后面的长轮询不好:) 对我来说，这是服务器推送最糟糕的事情。

ASP.NET 使用 ThreadPool 来处理请求。长轮询将占用 ThreadPool 线程。如果您有太多这些线程，您可能最终会出现线程饥饿(和眼泪)。作为一个大概的数字，100 不算多，但 +1000 是。

甚至 SignalR 团队也说针对 SingalR 优化的 IIS 框可能没有针对普通 ASP.NET 进行优化，他们建议将这些框分开。所以这意味着成本和开销。

归根结底，我建议使用长轮询 如果您正在解决业务问题 (而不是因为它很酷)因为那样会支付它的成本、管理费用和头痛。