Would you guys reconsider adding a disable auto refresh and a refresh button?
Whether its the auto refresh, or the gui, but its kinda challenging to use the monitor with a remote repository, it stops every interaction every couple of seconds
it shouldnt be blocking the UI…how is it stopping every interaction??
our goal would be to ensure this is asynchronous for the user
cb
Say, i try to resize one of the docked panes, but the GUI is locked up, so i have to click a couple times. When i see the lists update, then i can grab the edge.
Maybe its when the GUI gets populated?
I think its somehow related to the ‘job candidate filter’. At least, if i have that turned on, things go slow as molasses. With its off, its usable.
Also, this affects local machines too, not just ones accessing the repository/database remotely
On remote boxes, the with candidate filter on, its extremely slow, with it off, its still hanging up, but is faster.
sounds like something is blocking that shouldnt. the goal, like i said, is to be completely asynchronous so complaints that you currently have are a non-issue. i think that we have work to do…
i would hate to add a refresh button when we can just solve this and other issues forever by nailing all the blocking issues.
i’ll circle the wagons and figure this out! 
cb
Thanks for looking into this Chris!
Hey Laszlo,
I did some testing on our end here, and I think this issue is related to Limit Groups (with the Job Candidate filter). I know you guys use Limits in a pretty unique way, how many Limits do you have per Job, on average? If this number is pretty high (like, around 10), the Slave Candidate filter is probably going to start chugging pretty bad. If you’re at less than 5, it should probably be ok, though – I’m guessing this is the case.
What I think is actually the problem (especially since it’s way worse remotely than locally), is that one (or more) of the Limits you’re adding to Jobs hasn’t been created. I found a bug where if you click a Job that has a Limit that doesn’t exist, the Monitor will check the DB once for every slave to see if it can find that Limit. Obviously not optimal! We’ll fix this, but in the meantime, I’d check to make sure all the Limits you guys are adding to Jobs have actually been created in the DB.
Just a note, though, that having the Slave Candidate filter is always going to be less performant than not having it on. We have to do some fairly complex filtering, since we need to take a ton of things into account to accurately determine whether or not a Slave can render a Job. Obviously we’re gonna try to get this difference to be as small as possible, though!
Cheers,
- Jon
We basically cant use the job candidate filter right now, because it makes the gui unusable.
On average we have around 2-4 limit groups per job.
One thing i noticed, is that the limit groups are all lowercase in deadline, and have camel casing in the job itself. Is it case sensitive? (That would mean all are missing,… even though they are using stubs just fine…)
Naw, the casing shouldn’t matter – Deadline uses the lowercase version of the name as an ID.
laszlo, i know this is crazy, but is it at all possible for jon to connect to your repository to test your setup from wpg? i would like to ensure we can repro
cb
No, we could set something up, lets chat offline!
Hmm maybe its just a gui bug then, it seems like it handles them separately in the list:
Mmm, yeah, that should just be a GUI bug. The camel casing should still be treated the same as the lower-cased limit in all other cases. I’ll do some testing on our end to verify, though.
Either way, I’ve streamlined some of the Job Candidate filter code, to make it a bit faster. This should be in the next beta provided everything still works the way it should. Hopefully that will make it more bearable to use for you guys; if not, we’ll have to revisit again later.
For now we have advised users internally not to use the job candidate filter. Hopefully your improvements will help!
It seems that the only way people can really make the monitor usable for themselves now is by hiding the slave panel altogether. But even after that, im still getting complaints about the speed.
What would it take to have you guys reconsider the ability to disable auto-refresh? 
Laszlo -
there was a bug/flaw in how we were caching slave data and an additional issue dealing with the job candidate filter. those will be in B8 and should have an impact.
However, during detailed profiling we discovered a bottleneck in our datapipe to display. we are working on this now, it should appear in B9.
After we do those we would like feedback and can re-profile and find any other roadblocks and continue this discussion. As i noted earlier, i want to solve these issues rather than regress to the old/stale-data-that-you-refresh model. FIrst in my mind is the performance. Second is the UX experience and that incoming data isn’t messing up your workflow.
bear with us!
cb
I fully understand, i’m just between a rock and a hard place
i totally understand, and we are not taking your concerns lightly.
cb
Any way to tweak the refresh frequency? The 1-3 second interval is killing me, i cant even copy paste something from a log, cause every couple of seconds it locks up (and i cant scroll)