Is it possible to suspend the monitor updates? When sorting by certain fields (slave status for example), it keeps resorting every 1-2 seconds, making it hard to actually process machines by a certain property.
+1
If there are a large number of users running deadline monitor, we may not want them all continuously autoupdating due to the load that would create.
I think a more useful thing in this scenario would be a button to disable the dynamic sorting, not the actual updating of data. In other words, the data would still update, but if the dynamic sorting is turned off it won’t get re-sorted until you manually hit the headers to do it.
Would that meet your needs? This wouldn’t change the amount of hits to the database, but I think there are better solutions to that if that becomes an issue. Expecting end users to responsibly keep their auto-updates off doesn’t seem like the best way to deal with it.
- Jon
Auto-sorting would reduce the visual issue, i saw you added that to beta13 already, thanks! Will try out asap and see how good it feels.
The constant and frequent auto updating actually makes the GUI less responsive than it could be (at least i think thats whats causing it). When i try to move the separator between jobs & slaves, its quite slow (like 2-3 fps), with only about 900 jobs and 170 slaves.
I noticed that while i’m moving the separator, both slave & job windows are still auto updating, so i figured the responsiveness issue might be due to that?
We currently dont have a lot of users connected to deadline yet (maybe ~20), and only a portion of the farm, but i noticed that the mongo process already hovers around 50-70% cpu usage (on one core though, so maybe thats fine…if its multithreading well?). Whether its the constant flow of updates thats causing that or not, i dont know to be honest… just speculating
Hey Laszlo,
It’s not the refreshing that’s causing the slow down. It’s simply a known issue with resizing QT TreeView controls that contain lots of text. I confirmed this by disabling all auto-updating, in which case the moving of the splitters performed exactly the same as when auto-updating was enabled.
I should note that the Monitor only pulls over data from Mongo that’s changed, and only updates the rows that have changed. In beta 13, we improved this even further by only updating the actual cells in the row where data has changed.
From our tests, Mongo should handle the load you’ve described with ease, but If it becomes necessary, we would consider adding a configurable repository option that controls how often the Monitor updates its data (the same way you can configure how often a Slave looks for a job when it’s idle). Maybe we should just add it anyway, and that way you guys can dial it down if you think it’s necessary and see if it makes a difference.
Cheers,
- Ryan
Hmm… Thats weird. Assfreezer also uses Qt for its GUI and with 10.000 jobs, its resizing very quickly. Maybe its just displaying less columns or something like that?
That could be it. I’ve also noticed it depends on how much real estate the lists are taking up. For example, if I resize my Monitor to about half my desktop size, then the splitters are really fast. If I maximize my Monitor though, that’s when they start to slow down.
Yeah we have so much data there that maximized is basically the monitors only state :\
I’ll log this as a bug anyways. We can do some profiling and see if there is anything we can do to improve things.