Discussed in the Platform-Audiences sync as follow-up of T189526.
Because of the heavy weight DOM manipulation happening in the endpoints, there are some endpoints that are being starved because the event loop is being blocked for too long, producing GC problems and memory pressure and worsening the response times of the other endpoints that could be responding earlier.
We should make it so that the event loop is never blocked for too long so that the server can respond faster to things that are done and avoid blocking the event loop for too long.
Figure out the best way to improve the performance of the MCS server and services
- Investigate different alternatives, benchmark their performance characteristics and document the impact on the code/development. To decide which one we should apply to all the code/services. Suggested approaches to look into:
- Splitting synchronous CPU bound algorithms to be asynchronous and not go for longer than Xms, delaying work to nextTick after a certain amount of time.
- Having a pool of threads for CPU bound work (dom manipulations) and a pool for the network handling, and some sort of queue to send work to the CPU bound threads.