On Tue, Oct 27, 2009 at 11:00 PM, Aaron Boodman <[email protected]> wrote:
> On Tue, Oct 27, 2009 at 8:55 PM, Tim Steele <[email protected]> wrote: > > I can take a stab at more formal heuristics for bookmarks, at least. We > > will have a better idea of actual limiting parameters for bookmarks (as > in > > how many operations in a certain time frame is reasonable) once the > > ExtensionsActivityMonitor I just landed percolates and we can aggregate > > across representative sample data it produces. > > A couple thoughts: > > a) I think it is overly clever to hash the changes to the bookmarks > and count per unique-params. This can be easily or accidentally > defeated by just doing something like update({title:"foo"}), > update({url:"blech"}), over and over, anyway. Instead, at least for > bookmarks, I think a simple per-item-count is very reasonable. It > doesn't make sense to me to update the same bookmark more than a few > times per minute. An easy heuristic could be that updating the same > bookmark more than twice a minute sustained over 10 minutes. For > creates it's a bit tricker. In that case, maybe the best we can do is > the same combination of properties. > The update{foo} update{blech} case is most likely a different kind of failure, though, and I was thinking we could limit that with a generic cap on just the "number of updates in a period of time". From the data we have seen so far, most common is 'update{foo}' in a loop type behavior. But if the generic cap gets us far enough along, then I agree simpler is better. > > b) What is wrong with solving this by rate limiting the communication > between the Chrome sync client and the Chrome sync server? It seems > like that would be more foolproof; if the client tries to send too > many updates for any reason, they are rate limited. > We have this. The problem is that the user doesn't even realize the extension is spamming the server. Our server knows the client is producing a lot of traffic, that's all. So what happens is we limit the client and the user is left bewildered and helpless because a rogue extension is eating away his quota. What I just landed was a way to correlate how many of our sync commits originate from extensions, but we need to find a way to solve the problem once we learn from the data. The reason I suggested this, is because it dawned on me that this problem affects any extension author trying to send updates from Chrome to their servers. If extension Bob and Eve are installed, Eve can bring down Bob's service because of a silly bug. I was proposing we just add some layer of protection in here, because we can, to help our extensions developers out (and Chrome Sync in the process). > > - a > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
