Comment 12 for bug 1545092
Revision history for this message
| Brian Rosmaita (brian-rosmaita) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
> Do we have hard data on how much user X can slow down listing (or other db intensive operations) for user Y?
I don't have any "real life" data, but in devstack as user X, I added 1K images like the one above (128 additional properties, 128 tags), and when user X and user Y do simultaneous image-list requests, user X was getting a 500 and user Y was seeing the response time double for 2 public images + 1 private image. (But talk about a seriously underpowered database node!).
> Is this a quota issue or a rate limit issue?
As your create-and-delete example illustrates, it's probably both.
> I didn't try this, but I bet if user X creates all those images and than adds Y as a member to all of them, with v2 user Y won't be spammed, but user Y's image list query may be slowed down a bit (although since you don't have to marshall all those rows into JSON as you would with v1, it might not be a big deal).