Hi all,
some follow up on this. I've run another set of benchmarks, restructuring
the test so that
the maps at the various zoom levels are run in isolation, each one doing
its own
benchmark: this gives us a perspective on what's slow, and what improves
most
with the changes.
Also, wanted to check how the disabling of the server side cursor actually
helps,
and the analysis of the results led me to add another test, one in which I
don't
disable the server side cursors, but pump up the fetch size to 10k.
Here is a summary table with average response times (ms) and throughput
(requests/second),
the name of the map is the scale at which the map is painted.
ComparisonUnmodified master codeST_simplifyST_Simplify + no server side
cursorST_Simplify + 10000 fetch sizeAvg TimeThroughputAvg TimeThroughputAvg
TimeThroughputAvg TimeThroughput10million13256,9377010,7274711,1572511,595
million13286,8877910,6179210,6776810,792,5 million9748,9470011,9069411,97677
12,25125000012107,439678,981.0058,659828,8562500017175,3015255,941.5685,77
1.5745,8630000011107,9310378,431.0348,421.0458,4315000066512,0166512,78655
12,2463212,85
Observations:
* ST_simplify usage does indeed help at all scales in these benchmarks,
probably because even at 1:150000 we're
still somewhat away from the native resolution of the data (I'm setting
up the foss4g 2010 data in postgis again to test that one too with
st_simplify).
* Disabling the server side cursor helps most in the lower zoom levels, not
much in the middle ones, and slows down things in some cases. Which led me
to try out the usual setup (with server side cursors) and a higher fetch
size (10000), the results from the last column seem to suggest it's not the
server side cursor itself that costs, but the number of round trips between
geoserver and postgis to fetch data, which is cut by a factor of 10 when
switching form 1000 to 10000.
Apparently the lesson learned is that we don't need this change, but if one
knows a large amount of features need to be transferred to paint a map, a
large fetch size helps. It could be interesting, for the future, to make
fetch size a query hint, so that we can specify it on a per layer basis.
* The request at 1:625000 is by far the slowest one, and needs some extra
investigation, as this one probably has its own bottleneck in a different
place than the others.
Ah, another thing, the tests are giving quite erratic results, going up and
down by 10%, I've tried to run the tests multiple times and report back the
best result. Also, these results are not comparable with the previous ones,
as the way they are done it's different (before it was all zoom levels being
run all together, in this case instead each zoom level has 10 threads doing
those 60 requests, then stopping, and starting with the next zoom level,
and so on,
obviously resulting in lower performance due to the CPUs not being fully
utilized when each run closes to an end and only a few threads are waiting
for
completion).
Cheers
Andrea
--
*== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014 ==*
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
