Hmm, it doesn't seem to be entirely specific to this layer.
I tried with two other layers (again, this is the live system I'm testing
against now, so load balanced):
1) A simple polygon layer in Oracle, styled with a simple hatch fill. After
testing various thread counts, my peak throughput rate there is about 13r/s
(but the cost is that average response time doubles).
2) The EU_BASE layergroup that's in the shapefile I provided. 1 thread
response time is only 129ms there (finally something low! :-) ). I can get
21 threads on there and the throughput is a respectable 57.5r/s; the
response time doubles to 287ms (not really noticeable to the user in this
case though).
So Oracle is doing something to cripple it (surprise!), but that's on top
of the fact that any increase to throughput comes at the cost of average
response time.
I'm happy to conduct any other tests if you have them.
Cheers,
Jonathan
On 24 December 2013 15:23, Jonathan Moules <
[email protected]> wrote:
> Hi Andrea,
> Thanks for your investigations. I'm on Windows 64bit, so no native Image
> I/O here. I guess that means we should be equal (Geoserver 2.4.3 here) but
> clearly yours is much faster. In theory ours is somewhat optimised - we had
> Simone consult on it and tell me the stuff I'd missed.
> I agree the throughput is somewhat meaningless which is why I'm using ms
> averages. Also because that's how long the user will have to wait for their
> response which is more important to me than throughput.
>
> I chose that image size because that's the size of a single WMS request
> that our web-application makes for a 1280*1024 monitor (what many of our
> users have). The idea of the zoom threshold was to allow the different
> SLD's to take effect (though it's only one set with the Strategi stuff,
> albeit with a few scale-thresholded layers).
>
> =====
>
> I've now been running these against our live systems too (normally that'd
> be rather irresponsible, but it's Xmas eve and no-one is in;' probably the
> only day I can do this in the year!). Our live server, which has a few less
> cores (12), and three load-balanced instances is definitely much better
> able to handle 10 threads - I get a total average of 3316ms (2.9r/s) in
> that scenario (Oracle layers, PNG encoder). That uses 100% of the CPU (~30%
> per instance). The optimum seems to be about 8 threads; any more than that
> and the response time plummets.
>
> However it's just as slow for 1 thread as the test system was.
>
> Also, I'm new to Jmeter so don't know what the best plans are yet. This is
> a hybrid of Christians and what the internet presented and what seemed to
> work.
>
> ----
>
> In relation to your using PNGJ test - Your total average response times
> are about 1/3rd mine (2.5s compared to my 7.5s for the same thing), while
> using a heck of a lot less CPU power too. So either I have something really
> badly configured on my install, or Windows is even more crippled than I
> thought.
>
> Best,
> Jonathan
>
--
This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in error
please notify the sender immediately. All email traffic sent to or from us,
including without limitation all GCSX traffic, may be subject to recording
and/or monitoring in accordance with relevant legislation.
------------------------------------------------------------------------------
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
