Great to see the shootout results.
Also interesting to see the Amazon RDS announcement (MySQL based) with possibility of using quadruple extra large EC2 instances: db.m2.4xlarge - 68 GB of RAM http://aws.typepad.com/aws/2009/10/introducing-rds-the-amazon-relational-dat abase-service-.html http://aws.typepad.com/aws/2009/10/two-new-ec2-instance-types-additional-mem ory.html Maybe next shootout the DB layer could look at Amazon RDS(mySQL) and PostgreSQL/PostGIS using a quadruple extra large instance 68Gb RAM. After reading Todd Hoff's blog I'd be curious to see if PostGIS could be configured to make use of large memory capacities and how it affects performance: http://highscalability.com/are-cloud-based-memory-architectures-next-big-thi ng Thanks Randy From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Craig Miller Sent: Friday, October 23, 2009 8:38 PM To: 'OSGeo Discussions' Subject: RE: [OSGeo-Discuss] WMS Performance Shootout presentation/results I agree wholeheartedly. It looks like the bottleneck was the database. I've been privy to some MapServer tests done by testing teams over several months and the result there was always deploying the data with long update cycles to the middle tier disks instead of using the database. Only then could the performance of the actual map servers be evaluated. Performance shootouts/testing take time to do correctly as each run teaches you more and more about how your deployment architecture affects the results. Craig Geospatial Software Engineer Spatial Minds, LLC <http://spatialminds.com/> From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of antti roppola Sent: Friday, October 23, 2009 7:34 PM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] WMS Performance Shootout presentation/results It was really interesting. The very close results suggests to me that the bottlenecks were external to the WMS and more related to external limitations like the ability to supply things like I/O. It would be interesting to have profiling data on where the response time was spent. For Mapserver it'd be a simple case of running Valgrinf and KCacheGrind: http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindIndex Case point. We had an in house app for crunching big raster and KCacheGrind showed us that an external library was the biggest bottleneck. A. On Sat, Oct 24, 2009 at 10:39 AM, Jeff McKenna <jmcke...@gatewaygeomatics.com> wrote: For those that did not make it to Sydney, here is the WMS Performance Shootout presentation with results (GeoServer vs MapServer): http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout MapServer: power users who manage MapServer sites with high loads/map draws should take note of the results of MapServer CGI vs MapServer FastCGI, even in the case of Shapefiles and Rasters (yes, quite surprising). All: a lot of credit should go to Andrea Aime from GeoServer who worked very hard in bringing the MapServer team up to speed to learn the testing process. It was a great experience and we're already looking forward to next year. -jeff -- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ _______________________________________________ mapserver-users mailing list mapserver-us...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
