Paul +1<div><br></div><div>A typical WMS request is not tile based. The real world experience varies anything between 600x400 (512x512, if you want to consider tile) to 1024x768 (4x3 tiles). As Paul puts it, tiles based measurement is good only for tile based service (GWC, TileCache, ArcGIS TMS). If the benchmarking is on the GS, MS and ArcGIS and WMS/WFS as protocols then you should consider one agreed tile size and do more fine grain tests rather than diluting by testing few tile sizes. Make sure that content is NOT cached to measure the real throughput of the server.</div>
<div><br></div><div>imo, 600x400 is still on the lower side of the size, 800x600 is practical (slightly more than 3 tiles x 2tiles) and making it meaningful for vector rendering also. If one wants to play safe on system resources, then 600x400 is an ideal size. </div>
<div><br></div><div>When you do the benchmarking on the cached content, then one should use 256x256 since thats the tile size it stores. Then you can measure the throughput as, how many tiles per second. </div><div><br></div>
<div>my 2 cents.</div><div><br></div><div><br></div><div>Shanmugam</div><div><br></div><div>Geospatial Consultant</div><div>Singapore</div><div><br><br><div class="gmail_quote">2009/9/27 Paul Spencer <span dir="ltr"><<a href="mailto:pspencer@dmsolutions.ca">pspencer@dmsolutions.ca</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On 2009-09-27, at 10:40 AM, Andrea Aime wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
yestdays with Jeff we were talking about the size of the images that<br>
the tests will use to load the servers, whether it's better to<br>
hit the servers with common tile size requests (256x256) or common<br>
screen size request (anything between 640x480 to 1024x768, which also<br>
includes the common 768x768 base metatile request that tile caches<br>
love to issue).<br>
</blockquote>
<br></div>
personally I'd like to see the tests based on an assumption other than serving tile requests. Tile requests are typically cached for performance and only run once to generate the cache, either ahead of time in a seeding environment specially optimized for this or dynamically with some meta-tiling parameters. Both of these are somewhat special cases that are fine tuned by hand to achieve optimal performance, they don't suit more general purpose applications of GIS (turning layers on an off, etc). In the interest of keeping the task at hand manageable within the timeframe available, I think that picking a size that would suit most non-tiled applications like 600x400 would be a reasonable compromise.<br>
<br>
Cheers<br>
<br>
Paul<br>
<br>
__________________________________________<br><font color="#888888">
<br>
Paul Spencer<br>
Chief Technology Officer<br>
DM Solutions Group Inc<br>
<a href="http://research.dmsolutions.ca/" target="_blank">http://research.dmsolutions.ca/</a></font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Benchmarking mailing list<br>
<a href="mailto:Benchmarking@lists.osgeo.org" target="_blank">Benchmarking@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/benchmarking" target="_blank">http://lists.osgeo.org/mailman/listinfo/benchmarking</a><br>
</div></div></blockquote></div><br><br clear="all"><br>
</div>