Emmanuel Lécharny wrote: > There are two things that can be done here: > > - introduce a delay between each change ... > On the first point, it's just a parameter to add to the Batch control, I > guess. I would suggest to fill a JIRA with such a requirement for the sake fo > tracability.
May I suggest not to add a configurable delay but implement a configurable transaction rate (e.g. in modifies per second/minute) to make this easier to use? I run into the same requirement a lot and use another tool that allows me to configure a delay of x seconds every y transactions, which quickly becomes a time consuming trial & error session in order to balance throughput and server impact in an optimal way. Most often I need to run the batch just a bit slower han the server can process them, leaving room for regular production transactions to slip in between. If the batch is just a little too fast, the queue will pile up and prod transactions get delayed more and more over time. Some of my batch jobs run a whole weekend and a slight misconfiguration here can make the difference if all's fine on Monday morning or we'll have to wait the better part of the day until we can carry on with the next step e.g. of a migration. Configuring e.g. "max. 100 modifies/minute" is also user friendlier than setting a delay of "60 seconds div 100 minus average estimated transaction processing time". Obviously this requires continuous timing monitoring instead of adding a simple constand delay, but I think it would be worth the effort. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
