4 ms·

I helped Andrew ran the S3 tests. For us-standard bucket, we used an m3.medium instance in the us-east region, and for us-west bucket, we used a t2.micro instan

by khc 12y ago

I helped Andrew ran the S3 tests. For us-standard bucket, we used an m3.medium instance in the us-east region, and for us-west bucket, we used a t2.micro instance in the us-west-2 (Oregon) region. It is also possible that S3 somehow tries to pin requests from the same client to the same storage nodes. A better test setup would coordinate writing and reading across multiple clients, but is beyond the scope of this experiment. http://www.researchgate.net/publication/259541556_Eventual_Consistency_How_soon_is_eventual_An_Evaluation_of_Amazon_S3%27s_Consistency_Behavior/links/0deec52c6e04b49921000000.pdf http://www.researchgate.net/publication/259541556_Eventual_C... describes such a system and their results.

jayp 12y ago
Thanks for the clarification and the work Andrew and you put in.
jcrites 12y ago
Cool! Thanks for the research and experiment, and for following up on HN. I appreciated the attention to detail that was paid to documenting and explaining the consistency models. Be careful about running experiments from "t"-class instance types. Due to their ability to "burst" and consume extra CPU, the amount of system resources available to them is not consistent. This poses an experiment design challenge of ensuring that available system resources do not vary. It may be easier to run reliable experiments from another type. > Traditional Amazon EC2 instance types provide fixed performance, while T2 instances provide a baseline level of CPU performance with the ability to burst above that baseline level. They are intended for workloads that don't use the full CPU often or consistently, but occasionally need to burst. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instan... I am not sure if this will have meaningfully affected the accuracy of the results (probably not), but I thought I'd point it out for future reference.
- khc 12y ago
  Yup I am aware. For reference, the test took about 1000 minutes on the t1.micro (I misspoke earlier) and about 642 minutes on m3. I didn't test to see if the difference was due to machine class or region. Note that each run has 6 tests, each test is repeated 1000000 times and involves multiple requests.

by khc 12y ago

jayp 12y ago

Thanks for the clarification and the work Andrew and you put in.

jcrites 12y ago

Cool! Thanks for the research and experiment, and for following up on HN. I appreciated the attention to detail that was paid to documenting and explaining the consistency models. Be careful about running experiments from "t"-class instance types. Due to their ability to "burst" and consume extra CPU, the amount of system resources available to them is not consistent. This poses an experiment design challenge of ensuring that available system resources do not vary. It may be easier to run reliable experiments from another type. > Traditional Amazon EC2 instance types provide fixed performance, while T2 instances provide a baseline level of CPU performance with the ability to burst above that baseline level. They are intended for workloads that don't use the full CPU often or consistently, but occasionally need to burst. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instan... I am not sure if this will have meaningfully affected the accuracy of the results (probably not), but I thought I'd point it out for future reference.

khc 12y ago
Yup I am aware. For reference, the test took about 1000 minutes on the t1.micro (I misspoke earlier) and about 642 minutes on m3. I didn't test to see if the difference was due to machine class or region. Note that each run has 6 tests, each test is repeated 1000000 times and involves multiple requests.