I'm writing a windows service that needs to execute a task (that connects to a central server) every 30 days +- 5 days (it needs to be random). The service will be running on 2000+ client machines, so the randomness is meant to level them out so the server does not get overloaded.
What would be the best way to do this? Currently, I pick a random time between 25 - 35 days since the task last ran and use that.
Does anyone have a better way? Is there a better way?
What you've got sounds like a pretty good way to me. You might want to bias it somewhat so that if it executed after 25 days this time it's more likely to execute in more than 30 days next time, if you see what I mean.
Another alternative is that you could ask the central server for an appropriate "slot" - that way it could avoid overloading itself (assuming everything behaves itself).
Can the server tell the client when next to connect? If so the server could have a pool of 'scheduled connection slots' that are evenly distributed throughout the time interval. The server can distribute these as it likes and thus ensure an even spread.
Seems good enough. You might want to remove each day from the list as they are used (to ensure each day gets used at some point as by randomly selected some may never get selected!).
On top of the long term leveling, you could have the server return a status code if it is near capacity instructing the client to try again later. At that point you could just delay an hour or so, rather than 25-35 days.
I would certainly do what Jon suggests in his second paragraph, and move the logic to decide when to execute next to the server. This way you effectively have the clients at your control, and can make changes to your algorithm without having to re-distribute the app to your 2000+ machines.