Comet、responseText 和内存使用情况
有没有办法在不破坏 XHR 对象的情况下清除 XHR 对象的responseText？
我需要保持与 Web 服务器的持久连接打开，以将实时数据提供给浏览器。 问题是，有相对大量的数据通过（持续每秒数百K），因此内存使用是一个大问题，因为该连接必须保持打开状态至少几分钟。 尽管我发回的 JSON 已被压缩得尽可能小，但 responseText 很快就会变得非常大。
由于服务器端应用程序的工作方式，如果我使用 AJAX 风格的短轮询并在完成后销毁 XHR 对象，即使在解析 XHR 对象所需的几毫秒内，我也会错过大量重要数据。响应，创建一个新的 XHR 并将其发送出去。 我无法选择使用重叠请求，因为 Web 服务器一次只接受一个连接。 （不要问。）所以 Comet 正是我需要的模型。
我想做的是解析从服务器返回的每个 JSON 块，然后清除 responseText，以便我可以继续使用相同的连接。 但是，responseText 是只读的。 我发现的任何方法都不能直接清空它。
我在这里缺少图片的一部分吗？ 有谁知道我读完后可以使用什么技巧来释放responseText？ 或者服务器响应还有其他地方可以去吗？
我不包括代码，因为这实际上几乎是一个与代码无关的问题。 生成 XHR 并处理返回数据的 Javascript 例程非常非常简单。
Is there a way to clear out the responseText of an XHR object without destroying the XHR object?
I need to keep a persistent connection open to a web server to feed live data to a browser. The problem is, there is a relatively large amount of data coming through (several hundred K per second constantly), so memory usage is a big problem, because this connection must remain open for at least several minutes. responseText gets very big very quickly, even though the JSON I send back has been crunched as small as it can get.
Due to the way the server-side app works, if I use AJAX-style short polling and just destroy the XHR object when I'm done with it, I miss significant amounts of important data even in the few milliseconds it takes to parse the response, create a new XHR and send it out. I do not have the option to use overlapping requests, as the web server only accepts one connection at a time. (Don't ask.) So Comet is exactly the model I need.
What I would like to do is parse each JSON chunk as it comes back from the server, and then clear out responseText so that I can keep using the same connection. However, responseText is read-only. It cannot be directly emptied by any method I have found.
Is there a part of the picture I am missing here? Does anyone know any tricks I can use to free up responseText when I'm done reading it? Or is there another place the server responses can go?
I am not including code because this is really almost a code-agnostic question. The Javascript routines that spawn the XHRs and handle the returned data are very, very simple.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与其他响应相反，“长轮询”不是一个长连接。 “长轮询”是指按顺序排列多个连接，如果不需要响应，每个连接都设置为在相当长的时间内保持连接。 它们确实超时（通常大约 25-30 秒），然后重新建立新连接。 由于 HTTP1.1 允许重用现有连接，因此无需重新协商连接，因此几乎可以立即重新建立连接。
因此，只需使用多个请求即可。 由于重新建立连接的开销确实可以忽略不计，并且每个新连接都将使您能够销毁以前的响应文本，因此从性能/开销的角度来看，这是完全可行的解决方案，并且也可以解决您的内存问题。
[编辑]我是根据经验所说的，作为 WebSync 的作者之一。
Contrary to the other response, "long-polling" is not one long connection. "Long-polling" is many connections in sequence, each set up to stay connected for a reasonably long period of time if no response is needed. They do time out (typically around 25-30s), and then re-establish a new connection. Since HTTP1.1 allows for re-use of existing connections, the connection doesn't have to be re-negotiated, and can therefore be re-established virtually instantly.
So, just use multiple requests. Since there really is negligible overhead to re-establish the connection, and each new connection will enable you to destroy the previous response text, this is perfectly viable solution from a performance/overhead perspective, and would solve your memory issues as well.
[Edit] I'm speaking from experience, as one of the authors of WebSync.
这就是长轮询的工作原理。 您可以在最后读取的行号中保留一个索引，并从该点开始读取间隔的每个刻度。 这是一个长连接，因此也是一个长响应。
全新的
responseText意味着全新的连接。 但那样它就不再是彗星了;)That's just how long-polling works. You keep an index into the last line number read and with each tick of your interval read from that point onward. It's one long connection, thus one long response.
A fresh
responseTextwould mean a fresh connection. But then it wouldn't be comet anymore ;)