cache output of pbsnodes #466
Milestone
Comments
|
This has been discussed before and might be an open ticket also. |
|
Yeah, has been discussed, but I couldn't find a ticket. Let me look again. |
|
no previous ticket found, so I'll leave this open... |
|
I'm not sure if this effects any other machine, but if this is confined to Archer I would suggest closing it till we get active users on Archer. @andre-merzky can you confirm we don't have users on Archer right now? |
|
Yeah, that affects performance on all batch adaptors. Its 'just' an optimization though... |
|
I don't have the numbers, so can't judge the severity of the performance delay. Do you want to keep the ticket open since this affects all adapters? |
andre-merzky
added
priority:low
type:enhancement
topic:performance
and removed
type:performance
labels
|
Yeah. I set the priority to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Archer, for example,
pbsnodes -atakes almost a minute. We do that over and over again. Assuming that PBS configuration is kinda static during the lifetime of an application, this should be cached on adaptor level (per job service URL). That is probably true for other information as well (paths to qsub etc) which all add quite a number of roundtrips for nothing, but pbsnodes is the one which takes most time.The text was updated successfully, but these errors were encountered: