Key: |
QB-1167
|
Type: |
Improvement
|
Status: |
Resolved
|
Resolution: |
Fixed
|
Priority: |
Major
|
Assignee: |
Unassigned
|
Reporter: |
Karim Heredia
|
Votes: |
0
|
Watchers: |
0
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 10/Dec/11 06:36 AM
Updated: 04/Jan/12 01:57 PM
|
|
Component/s: |
None
|
Affects Version/s: |
3.1.67,
4.0.19
|
Fix Version/s: |
4.0.22
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
When setting the schedule for a configuration, QB provides two values by default:
* 0 0 1 * * ? for cron schedule
* 300 seconds for periodical schedule
What we have encountered is that most developers are happy with the default options.
However, when the number of configurations grows to a large number (in the order of thousands), it turns out that most configurations check for changes on repositories at the same time. The problem is not only a QB's side, but also the SCM server and other related resources, as now they get a burst of requests at one time, while the rest of the time QB does not check much.
We have fixed this manually by:
* Providing "random" values for schedules.
* Using mainly prime numbers for setting periodical schedules (for example, 293 or 307 seconds instead of 300). In this way, it's less likely that two configurations will coincide when checking for changes.
My suggestion is that instead of leaving one single default value, you do this:
* Provide an administrative option to set the range of valid default schedules
* QB then randomizes (and preferably chooses a prime number) when setting a new schedule.
|
Description
|
When setting the schedule for a configuration, QB provides two values by default:
* 0 0 1 * * ? for cron schedule
* 300 seconds for periodical schedule
What we have encountered is that most developers are happy with the default options.
However, when the number of configurations grows to a large number (in the order of thousands), it turns out that most configurations check for changes on repositories at the same time. The problem is not only a QB's side, but also the SCM server and other related resources, as now they get a burst of requests at one time, while the rest of the time QB does not check much.
We have fixed this manually by:
* Providing "random" values for schedules.
* Using mainly prime numbers for setting periodical schedules (for example, 293 or 307 seconds instead of 300). In this way, it's less likely that two configurations will coincide when checking for changes.
My suggestion is that instead of leaving one single default value, you do this:
* Provide an administrative option to set the range of valid default schedules
* QB then randomizes (and preferably chooses a prime number) when setting a new schedule. |
Show » |
There are no comments yet on this issue.
|
|