Hi List,
I’m having issues with tile rendering speeds for my basemap. It’s taking up to 45 seconds to return a non-cached tile.
The data is coming from some Oracle tables (spatially indexed; plus the filter attribute is indexed too) and there’s a fairly complex series of SLD’s behind it.
Test results for a single tile below. In the attached zip is an over-compressed JPG version for the list; but the outputs are PNGs (this one is about 100KB).
I did three tests in this order for the same tile from different GeoServer instances (but all calling the same database).
2.4.0-Test - 17 seconds
2.3.5-internal - 5 seconds
2.3.5-external - 6.8s
As you can see it got faster once Oracle figured out what was going on. But it was still very slow.
Also in the zip is the GeoTools level logs. It’s clear most of the delay is Oracle, but the tile rendering is also quite slow taking over a second in all instances if I’m reading this right.
I also tried it with a older, slightly simpler style but got similar times:
2.3.5-external - 6seconds
2.3.5-internal - 3.8seconds
2.4.0-Test - 9seconds
I’ll try the new PNG encoder, but that isn’t likely to help with the fundamental issue.
Can anyone suggest why things (including the oracle) are so slow? It used to be faster.
Many Thanks,
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.
tile-speed issues.zip (22.4 KB)
If both the database query and the rendering step inside GeoServer are taking a long time, that suggests to me that you are simply fetching and processing a lot of data. Do you have an idea of how many features are in the tiles that are slow to render? Are tiles at larger scales (covering less space hopefully implies covering fewer features) faster to render?
···
On Mon, Oct 14, 2013 at 8:28 AM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:
Hi List,
I’m having issues with tile rendering speeds for my basemap. It’s taking up to 45 seconds to return a non-cached tile.
The data is coming from some Oracle tables (spatially indexed; plus the filter attribute is indexed too) and there’s a fairly complex series of SLD’s behind it.
Test results for a single tile below. In the attached zip is an over-compressed JPG version for the list; but the outputs are PNGs (this one is about 100KB).
I did three tests in this order for the same tile from different GeoServer instances (but all calling the same database).
2.4.0-Test - 17 seconds
2.3.5-internal - 5 seconds
2.3.5-external - 6.8s
As you can see it got faster once Oracle figured out what was going on. But it was still very slow.
Also in the zip is the GeoTools level logs. It’s clear most of the delay is Oracle, but the tile rendering is also quite slow taking over a second in all instances if I’m reading this right.
I also tried it with a older, slightly simpler style but got similar times:
2.3.5-external - 6seconds
2.3.5-internal - 3.8seconds
2.4.0-Test - 9seconds
I’ll try the new PNG encoder, but that isn’t likely to help with the fundamental issue.
Can anyone suggest why things (including the oracle) are so slow? It used to be faster.
Many Thanks,
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.
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
–
David Winslow
Boundless - http://boundlessgeo.com/
Hi David,
There’s a reasonable amount of features per tile. For the busiest tiles (urban areas), there are the following numbers as an example for the tile I’ve used previously in this thread:
Polygons - 16 seconds for oracle to respond - 14,740 features
Feature Lines - 4.4seconds for Oracle - 39,954 features
Boundary Lines - <1 second - 45 features
Text lines - 2.2 seconds - no results.
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.
···
The Polygons and Feature Lines are purely spatial queries with no non-spatial filters. This is odd because in the SLD, every single entry has a filter of some sort (all on the same column).
So it seems GeoServer is choosing to do the filtering server side rather than database side. Yet for the other two layers (boundary and text), it does the filtering database side.
You’re correct that zooming in, the tiles render faster.
Jonathan
On 14 October 2013 15:00, David Winslow <dwinslow@anonymised.com> wrote:
If both the database query and the rendering step inside GeoServer are taking a long time, that suggests to me that you are simply fetching and processing a lot of data. Do you have an idea of how many features are in the tiles that are slow to render? Are tiles at larger scales (covering less space hopefully implies covering fewer features) faster to render?
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Oct 14, 2013 at 8:28 AM, Jonathan Moules <jonathanmoules@anonymised.com…4942…> wrote:
Hi List,
I’m having issues with tile rendering speeds for my basemap. It’s taking up to 45 seconds to return a non-cached tile.
The data is coming from some Oracle tables (spatially indexed; plus the filter attribute is indexed too) and there’s a fairly complex series of SLD’s behind it.
Test results for a single tile below. In the attached zip is an over-compressed JPG version for the list; but the outputs are PNGs (this one is about 100KB).
I did three tests in this order for the same tile from different GeoServer instances (but all calling the same database).
2.4.0-Test - 17 seconds
2.3.5-internal - 5 seconds
2.3.5-external - 6.8s
As you can see it got faster once Oracle figured out what was going on. But it was still very slow.
Also in the zip is the GeoTools level logs. It’s clear most of the delay is Oracle, but the tile rendering is also quite slow taking over a second in all instances if I’m reading this right.
I also tried it with a older, slightly simpler style but got similar times:
2.3.5-external - 6seconds
2.3.5-internal - 3.8seconds
2.4.0-Test - 9seconds
I’ll try the new PNG encoder, but that isn’t likely to help with the fundamental issue.
Can anyone suggest why things (including the oracle) are so slow? It used to be faster.
Many Thanks,
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.
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
–
David Winslow
Boundless - http://boundlessgeo.com/