I don't have actual numbers handy to back this up, but a rough comparison from what we observed rendering relatively complex maps was that EBS storage was perhaps 2-4 as slow as a local dell desktop running linux with eSATA 1TB drives (not high end hardware for sure). Using glusterfs was 8+ times as slow. We ended up using EBS as we could fit all our data onto a 1TB disk, it replicates reasonably quickly once snapshotted so to scale we start a new instance and replicate the EBS volume behind a load balancer. Adding more servers and copies of the data makes up for the slower IO speed somewhat but every map draw still takes 2-4 times longer than using dedicated hardware. On the other hand, it is very cost effective for scaling. But for the amount of data that you are talking about, scaling by duplicating the EBS volumes would be very expensive and I really thing shared storage via glusterfs is a non-starter for that kind of volume of data if you want any kind of reasonable render time.
On 2011-01-28, at 10:57 AM, [email protected] wrote: > What do you exactly mean by pathetic I/O on S3/EBS? __________________________________________ Paul Spencer Chief Technology Officer DM Solutions Group Inc http://research.dmsolutions.ca/ _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
