Comments on: Understanding Cloud Benchmarks

Comments on: Understanding Cloud Benchmarks http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/ Wed, 08 Feb 2012 05:24:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: randybias http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-375 randybias Tue, 02 Jun 2009 01:28:54 +0000 http://www.engineyard.com/blog/?p=715#comment-375 More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations: - This is a theoretical maximum (~100MBps is more likely) - There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload. See following for some examples of work load I/O profiles: <a href="http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx" target="_blank">http://blogs.msdn.com/tvoellm/archive/2009/05/07/...</a> More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/…

]]> By: randybias http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-376 randybias Tue, 02 Jun 2009 01:28:54 +0000 http://www.engineyard.com/blog/?p=715#comment-376 More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations: - This is a theoretical maximum (~100MBps is more likely) - There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload. See following for some examples of work load I/O profiles: <a href="http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx" target="_blank">http://blogs.msdn.com/tvoellm/archive/2009/05/07/...</a> More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/…

]]> By: randybias http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-377 randybias Tue, 02 Jun 2009 01:28:54 +0000 http://www.engineyard.com/blog/?p=715#comment-377 More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations: - This is a theoretical maximum (~100MBps is more likely) - There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload. See following for some examples of work load I/O profiles: <a href="http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx" target="_blank">http://blogs.msdn.com/tvoellm/archive/2009/05/07/...</a> More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/…

]]> By: randybias http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-378 randybias Tue, 02 Jun 2009 01:28:54 +0000 http://www.engineyard.com/blog/?p=715#comment-378 More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations: - This is a theoretical maximum (~100MBps is more likely) - There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload. See following for some examples of work load I/O profiles: <a href="http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx" target="_blank">http://blogs.msdn.com/tvoellm/archive/2009/05/07/...</a> More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/…

]]> By: randybias http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-379 randybias Tue, 02 Jun 2009 01:28:54 +0000 http://www.engineyard.com/blog/?p=715#comment-379 More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations: - This is a theoretical maximum (~100MBps is more likely) - There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload. See following for some examples of work load I/O profiles: <a href="http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx" target="_blank">http://blogs.msdn.com/tvoellm/archive/2009/05/07/...</a> More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/…

]]> By: randybias http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-380 randybias Tue, 02 Jun 2009 01:28:54 +0000 http://www.engineyard.com/blog/?p=715#comment-380 More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations: - This is a theoretical maximum (~100MBps is more likely) - There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload. See following for some examples of work load I/O profiles: <a href="http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx" target="_blank">http://blogs.msdn.com/tvoellm/archive/2009/05/07/...</a> More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/…

]]> By: Alfonso http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-344 Alfonso Fri, 29 May 2009 15:00:27 +0000 http://www.engineyard.com/blog/?p=715#comment-344 Hi Nick Sorry for the link but we found that we have some copyrighted material from ESA and we have to wait for a permission. As soon as they give us the Ok I will put it online again. Cheers Alfonso Hi Nick

Sorry for the link but we found that we have some copyrighted material from ESA and we have to wait for a permission. As soon as they give us the Ok I will put it online again.

Cheers
Alfonso

]]> By: Nick French http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-328 Nick French Thu, 28 May 2009 17:47:50 +0000 http://www.engineyard.com/blog/?p=715#comment-328 Hi Alfonso - thanks for the comment. I'm interested in seeing your presentation slides, but the link you provided in your comment is broken. Hi Alfonso – thanks for the comment. I'm interested in seeing your presentation slides, but the link you provided in your comment is broken.

]]> By: Alfonso http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/comment-page-1/#comment-325 Alfonso Thu, 28 May 2009 09:32:53 +0000 http://www.engineyard.com/blog/?p=715#comment-325 It is normal for very large distributed systems that you have to relax you HPC requirements if you want high scalability. We have run a test at the European Space Agency with the Amazon Cloud. And we have come up with similar conclusions. We have shared the presentation slides <a href="http://tinyurl.com/pz9xjt" target="_blank">http://tinyurl.com/pz9xjt</a> All the best, good post! Alfonso <a href="http://www.linkedin.com/in/alfonsooliassanz" target="_blank">http://www.linkedin.com/in/alfonsooliassanz</a> It is normal for very large distributed systems that you have to relax you HPC requirements if you want high scalability.

We have run a test at the European Space Agency with the Amazon Cloud. And we have come up with similar conclusions.

We have shared the presentation slides
http://tinyurl.com/pz9xjt

All the best, good post!
Alfonso
http://www.linkedin.com/in/alfonsooliassanz

]]>