I have received multiple reports from users of a Web-based GIS application we have rolled out one to two year ago, complaining the application becomes unstable/unresponsive. After a brief investigation, I found that requests from the third party Map API take up most available connections of browsers (pulling dynamic layers, they are images), and the processing time of these requests were prolonged due to a large number of users (1xx vs 1x as planned), so the requests from our own API had to wait for free connections and eventually timeout, the overview of such a situation is like this:
requests from the Map API (busy) | requests from our own API to get data from DB to display (waiting) | requests from our own API to post data to DB (waiting) ** A FEW MOMENTS LATER ** requests from the Map API (still working...) | requests from our own API to get data from DB to display (timeout) | requests from our own API to post data to DB (timeout)
what I want to achieve is moving any requests from our own API to get data from DB in front of requests from the Map API, however, are no way to tell the Map API it should wait for (more important) requests from our own API before they could update the map. I did came across this question and planned to propose a solution: open a socket before initializing the Map API, and requests from our own API to get data will go through it instead of using ajax. I wonder...
Should I also make the requests from our own API to post data to DB also using the socket? As rewrite API work with Ajax to Socket takes time, and users should post updates after they get the data and the updated map.
Also, making every request from our own API via socket seems moves the request congestion from Ajax to the socket.