You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If running two separate DQM square mirror instances, both try to get information from the P5 machines at the same time, by using the playback RUBU as an intermediate. This doesn't work well, which is why the cmsweb-test4 deployment needs to ask for updates as little as possible (currently once per half an hour).
If, for example, the service is running at the same update rate (every 30s) in two separate instances, the result is that neither is updated in time:
What needs to be investigated:
Perhaps it's the get_cluster_status endpoint which slows down the RUBU by having to open websockets to each of the FU machines?
Could the requests from the mirror be minimized, by aggregating them so that one request gets all the updates for one host?
Is it related to the fff_dqmtools service itself?
The text was updated successfully, but these errors were encountered:
If running two separate DQM square mirror instances, both try to get information from the P5 machines at the same time, by using the playback RUBU as an intermediate. This doesn't work well, which is why the
cmsweb-test4
deployment needs to ask for updates as little as possible (currently once per half an hour).If, for example, the service is running at the same update rate (every 30s) in two separate instances, the result is that neither is updated in time:
What needs to be investigated:
get_cluster_status
endpoint which slows down the RUBU by having to open websockets to each of the FU machines?fff_dqmtools
service itself?The text was updated successfully, but these errors were encountered: