> If you ignore the fact that these aren't actually static objects
It depends what you call a static object.
If the content of your object is stored somewhere and you can just send it without transformations, it's some kind of static object.
Now, looking at a single S3 bucket as a key-value store, with some kind of routing mapping an object's URL to a set of shards each containing the object, one could argue it's serving static objects.
> require a lot more computation to work out where they are and where they need to go
I hope not. I would bet it's not very far from serving a file from the filesystem. There may be a lot of i/o contension though.
> in fact, that number should be much higher
Yes, very probably, and that only makes the 1.1M RPS number seem even less impressive - for amazon.
> 1.1M RPS is the amount they actually serve, not how much they can serve
My whole point was this number of requests seem low for amazon, not that they couldn't handle more.
It depends what you call a static object.
If the content of your object is stored somewhere and you can just send it without transformations, it's some kind of static object.
Now, looking at a single S3 bucket as a key-value store, with some kind of routing mapping an object's URL to a set of shards each containing the object, one could argue it's serving static objects.
> require a lot more computation to work out where they are and where they need to go
I hope not. I would bet it's not very far from serving a file from the filesystem. There may be a lot of i/o contension though.
> in fact, that number should be much higher
Yes, very probably, and that only makes the 1.1M RPS number seem even less impressive - for amazon.
> 1.1M RPS is the amount they actually serve, not how much they can serve
My whole point was this number of requests seem low for amazon, not that they couldn't handle more.