Craig Miller ha scritto:
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.
Actually running the benchmarks it looked the CPU was the bottleneck, we had 25% cpu load in the single test (so 100% of the one CPU used by that test, out of the 4 available) and during the higher loads the CPU usage was jumping between 80% and 100% (so almost all 4 cpu maxed out). The database server was hardly using more than 25-30% of its CPU and the network shouldn't have played the bottleneck either (past experience suggests it takes a tilecache to actually turn a 100Mbit line into a bottlenek), thought we don't have numbers for that During the benchmark I had very little time to run profilers, but the few times I've tried in GeoServer the time seemed to be splitted quite equally between data fetching, actual drawing, and output image encoding... which is kind of the worst thing you can get out of a profile run, since it does not point to any culprit. Getting a profile out of MapServer is surely going to be interesting, the codebase is smaller and there is no garbage collection going on so the results should be clearer. Looking forward to see those results :-) Cheers Andrea _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss