0

In a WebSocket fallback using HTTP streaming I can see that XmlHttpRequest#responseText is invoked each time the readystate changes (and is >= 3).

The WHATWG living standard says that the text response is

...the result of running decode on received bytes using fallback encoding charset.

I think this means that a new string with a size corresponding to the result of encoding into UTF-16 all data received since the HTTP streaming request was made is created each time the readystate changes in this way.

I have observed periodic (i.e. for the periods where the HTTP streaming response buffer is larger - it is reset periodically) large amounts of memory churn in the JavaScript heap when using this technique with around five messages inbound to the client per second and think it is linked to the above approach.

Does this sound a reasonable analysis?

Has anyone found any techniques to reduce the impact on the memory subsystem of this HTTP streaming technique (eg. shortening the life of each HTTP streaming connection)?

Ben Aston
  • 53,718
  • 65
  • 205
  • 331
  • 1
    Your analysis is correct. For which browsers do you still need fallback? – Anne May 06 '17 at 06:11
  • IE11, Firefox 40+ and Chrome 40+ unfortunately due to current backend infrastructure not supporting WebSockets. Do you have experience in this area? – Ben Aston May 06 '17 at 07:10
  • I help maintain both standards (XMLHttpRequest and WebSocket), but I don't think I can offer much practical advice here. Sorry. – Anne May 06 '17 at 13:01

0 Answers0