These two views don’t have any bindings that would contain large amounts of data. They are not “larger” or more complex than other views in the project. They may even be a bit less complicated/smaller that some others.
I would think that if were a view specific issue, the two views would also be crashing the WebSocket on our QA and Val servers, since the views/projects are the same across all servers.
Sorry, but without really in-depth access I’ve reached the extent to which I can help diagnose the problem. You could contact support to help examine the environments in question and locate the difference, but I’m not in a position to make guesses or troubleshoot your deployments. My help here on the forums boils down to things I know or can research.
You were right! There was some old content that had been disabled (display set to false), but there was a query binding that was still active. Since the three servers have separate DBs, the other two were not accumulating as much data as the production server, since they are only used for testing, not nearly as much data has built up in their DBs. The biding on the production server created a dataset with 58K+ rows of data.
The reason for the disabling and not summarily deleting the content was due to the nature of the facility shifting back and forth on what they may or may not want over a period of time. So in the future, if we are directed to disable content, we need to be aware of any binding and such that could be problematic.
We did have Tech Support remote in to look (before we found the above content) and they increased the socket max value. That got us up and running. I’ll be working on a bug fix branch to remedy this and look through the other content to make sure there isn’t other monsters hiding, and waiting to attack!
Thanks for your help!