TQ Berg - 24/Feb/09 02:58 PM This might be causing a slowdown of our Perforce server. In 1.5 days, there were 175,000 Pulse/Perforce operations (for ~ 90 Pulse projects) versus 21,000 TeamCity/Perforce operations (for ~ 270 T.C. projects). We have noticed a slowdown in Perforce recently and we are trying to determine if this is related to Pulse/Perforce interactions. Ideas?

Daniel Ostermeier - 24/Feb/09 10:27 PM I'm no expert with the Perforce implementation (and Jason is on holidays until next week). One thing to check is the polling frequency of the projects. Tweaking the polling frequency may help reduce the load (even temporarily) until this jira is implemented.

TQ Berg - 25/Feb/09 12:45 PM This could just be us having a lot of Perforce users. Our Pulse polling was set for every 3 minutes, but even then, it seems like the Pulse/Perforce operations should have been closer to 50,000. The TC comparison wasn't accurate, since, unknown to me, someone had throttled back the polling to once an hour (not so good for CI).

jason - 01/Mar/09 09:50 AM Hi TQ, The numbers you quote seem about right for a 3 minute polling interval over 36 hours. Doing the math, this comes out at approximately 3 perforce operations per project per polling interval, which is expected (output template workspace, update polling workspace, get latest revision for workspace). This could be reduced to 2 operations in most cases if we optimised out the second step when there are no differences), and even down to 1 operation if the mapping did not come from a template client. By far the most significant reduction would come from turning off polling and using a Perforce trigger and the remote API to kick off builds instead. Of course this requires significant custom work so is only something you would do if the polling is causing real problems.

jason - 23/Nov/09 05:29 PM Implemented in change 7076.