Slow polling

[user6330]

CONTEXT
I have two go-cd server installed in two different servers (GO1 in M1 and GO2 in M2) with gitpathmaterial installed manually and a git-server installed in another server (GIT in M3) under the same subnet of the M2.
Go-cd version is 19.8.0 and GitPathMaterial version is 1.2.3. I already know that is obsolete and we have planned to upgrade but actually we need to find a way to work out.

PROBLEM
The pipelines linked with gitpathmaterial in M1 don't start at the same time of the M2s. Reading the GitPathMaterial Log of M2 is constantly writing, as if it pings frequently. M1's Log instead it seems frozen but if I change some reference in material it write something, so it's working but it's not polling at the same way of M2s.
I found out that when I ping from M2 the git server the time response is below 1 ms (eg. time=0.478 ms). From M1, instead, the ping is time=19.7 ms. I don't know if it's related but there is a way to set a time of polling? or to force the polling so it starts immediatly the pipeline?

[chadlwilson]

What's the approximate difference in time it takes to trigger between M1 and M2? Seconds? Minutes?

The polling interval is effectively controlled by the GoCD server and the speed at which that server can check for changes, not the plugin - although if the plugin is slow, the server might not be able to process enough materials.

It's possible to change the server configuration polling frequency with cruise.material.update.interval system property, but you probably want to check if the two servers have matching configuration. If one of them has less resources, or much slower disk speed than the other, that may also cause problems.

The other possibility, even if they have identical configuration, is that one server has many more materials and has a backlog to get through, so it triggers changes more slowly than the other.

You'd need to check the server logging to see what it is reporting related to checking materials for updates.

Does M2 have far fewer materials it is monitoring than M1? The location of M2 closer to the git server might just be a co-incidence.