My Meteor App experiences a severe performance degradation when run behind the firewall of a certain french bank.
On looking at my server logs and APM, it appears that the client is calling all its current subscriptions afresh every 30 seconds or so (i.e. the function that is passed to Meteor.publish is rerun. I suspect that the client then receives the complete data set of every subscription each time. Which makes it very slow and pretty unusable (according to the individual trying to use the app from within the bank).
I presume I am right in thinking that this would not be the symptom if Meteor is simply falling back on SockJS? And I am assuming this must be due to some sort of communications restriction implemented by the bank.
I am not able to either replicate this or diagnose it from within the bank, so I’m afraid my request for ideas (at this time) is only based on this rather sketchy description. But I’m hoping someone might have some insight even so?
I’m not sure it would be the fallback - more likely it is a connection timeout with the websocket, whenever the connection dies meteor reconnects and reruns all the subscriptions
When working behind a firewall it can get very messy. What we did in this case is that we asked for access to a local machine view screenshare (e.g. google remote desktop or teamviewer).
What we found is that the firewall had problems with websockets. It would drop them out randomly. If this is your case try reverting to xhr-only by setting DISABLE_WEBSOCKETS=true in your command line when building. It will result in worse experience than full-fledged websocket (more cpu server-side, slower updates) but solves the issue in this case.
Thanks for responses …Yes, I see, this must be due to disconnections.
Is there a way by which I can force a specific client to fallback to SockJS (xhr-only) without turning it off for every-one else with DISABLE_WEBSOCKETS=true; I can’t see how to do that. Seems a shame to disable sockets when it works for all my users bar one!
The only way we were able to do it was by hacking socket-stream-client (or a similar name). Right now it starts with websockets and if it fails (has to be catastrophic failure) it falls back on xhr. The problem is that this package starts running right away.