On Fri, Mar 1, 2013 at 5:34 PM, Parth Jagirdar <parth.jagir...@citrix.com> wrote: > All, > > API throttling number can be set to anything at this point. > > Suggestions here is to have this number set to a value that is "greater than" > number of API that can be fired by any potential action on UI. > > Minimum API for throttling that can be set < Number of API's Any action can > fire in unit time. > (unit time is 1 second) > > > That said say action X fires 10 API in 2 seconds than having 10 as min number > is safe. Or even 8 if we have decent idea of intervals they get fired at.. > But for action Y that fires 20 in 2 seconds with 15 in first seconds than 15 > as min number is required to avoid undesirable effects > > > Real life example, > > Login as user (not admin; throttling doesn't apply to Admin) fires about 8 in > total. (in less than a second which is the unit we are using in API > throttling) > > Now if this number is set to anything less than this will have unpleasant > effect on UI. > > Including unwanted error (HTML 429) and partial UI screen rendering. > > > So to hardcode numbers or just document and leave on admins to exercise > cautions or ... .. Please provide your suggestions /inputs. > > Track it here: https://issues.apache.org/jira/browse/CLOUDSTACK-1483 > > > Thanks, > ...Parth >
IMO - people should not be surprised when they upgrade to a new feature release. The default should be no throttling. We also have to remember that there are other things besides the UI that interact with the API. If I were to use Cloudcat or knife-cloudstack and provision n-number of nodes, I suspect I'd rapidly find myself throttled/blacklisted. Any sane default that's remotely useful for most folks will be awful for high-end sophisticated users. Adding new functionality that breaks things by default for folks is just a bad idea. --David
