Hey all,
can I draw your attention for a minute to
http://jira.codehaus.org/browse/GEOS-5009 ?
I've been struggling to integrate gwc with the GeoServer Dispatcher
(attending a customer requirement) so that it can engage into
control-flow throttling, and found a big performance hit, which at
first I thought it could make sense as there are a couple more things
going on when directing the requests through the GeoServer Dispatcher
as opposed to going directly through the GWC dispatcher.
But a profiler session shown up that the threads were blocking at
Method.invoke, something we can't handle. Hence the proposal in the
issue and the attached throughput comparison chart.
Please let me know if it seems ok to apply that patch on trunk.
Cheers,
Gabriel
2012/3/19 Gabriel Roldán (JIRA) <jira@anonymised.com>:
Gabriel Roldán created GEOS-5009:
------------------------------------Summary: Provide a way for the dispatcher to call a service operation avoiding reflection, for cases where it impacts performance Key: GEOS\-5009 URL: https://jira.codehaus.org/browse/GEOS-5009 Project: GeoServer Issue Type: ImprovementAffects Versions: 2.1.3
Reporter: Gabriel Roldán
Assignee: Gabriel Roldán
Fix For: 2.1.4
Attachments: DirectInvocationService.patch, DirectInvocationService.pngWhen the OWS Dispatcher executes a service operation, it does so by using the reflective call {{Method.invoke}}. Now, both Sun JDK6 and 7 implementations come with quite a performance penalty in doing so (although Java7 a bit less than Java6), due to synchronized blocks inside {{Method.invoke}}.
This affects the performance of service operations that execute fast and are meant to be called by a large number of concurrent requests. Profiler shown they're blocked at this call for up to 70% of the time. For instance, I've been working on letting GWC tile requests engage into the Dispatcher so that it's possible to throttle them with control-flow.The attached patch introduces an interface {{DirectInvocationService}}, that service beans can __optionally__ implement, so that the Dispatcher has a more direct way of invoking an operation than using reflection. So basically there's no difference for any existing service implementation other than an instanceof check at the Dispatcher itself, at least the service bean chooses to implement this interface.
The attached graph shows a performance comparison for the integrated gwc under different loads (with a hot cache):
- gray bars: the raw performance of the integrated gwc without going through the dispatcher
- red line: the performance when going through the Dispatcher as it is today (calling Method.invoke)
- green line: the performance after the gwc service implements {{DirectInvocationService}} and hence the Dispatcher doesn't call Method.invoke--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.