bpatzak
commented
6 days ago This is done in https://github.com/mupif/mupif-monitor/commit/c20e8ab9996b10734bc1fe837bb6395187a3dc07
I am currently trying to figure out why https://musicode.mupif.org/safe-api/scheduler-status2/ is so slow The endpoint calls schedulerInfo method defined in monitor.py.
In schedulerInfo method there is
- s.getStatistics() call that returns immediately
- s.getExecutions(status='Running') which returns array of size 140 (in musicode), also including records with other statuses (Finished, etc). this method calls restApiControl.getExecutionRecords(status=status). So this call is the root cause of slow response of this endpoint. Filtering does not work properly.
- Then the endpoint loops over recieved executions and tries to get tail of the log. Not sure if this is needed at all.... (at least the monitor does not seem to need the data on running executions, it shows only the data on "lastExecutions"
export MUPIF_NS="172.22.2.1:10000"import Pyro5
import mupif
ns=mupif.pyroutil.connectNameserver()
query = ns.yplookup(meta_any={"type:scheduler"})
uri=query['mupif.scheduler'][0]
s = Pyro5.api.Proxy(uri)
executions = s.getExecutions(status='Running')
len(executions)140
stanislavsulc
eudoxos
Geolocation is queried remotely after every update of VPN status (every few seconds), for each client; this should be cached (with infinite TTL). It also causes the markers to briefly disappear and appear one after another during the refresh.
https://github.com/mupif/mupif-monitor/blob/f76b34b1b37ac9621f259e20f713275257993be2/src/stores/vpnStat.js#L44-L56