Hi,
this mail contains an updated patch to speed up coverage
rendering that me and Simone have been developing in our
spare time.
The patch works in a wider number of cases compared to the
original one posted in December, yet it still fails to
render images properly under some conditions.
It still targets the single raster case, if there is anything
more in the map context the normal rendering path will be used
instead.
It should work fine with RGB, RGBA and indexed color
inputs thought, and should be always returning results with
the proper size.
The patch is also still favouring ease of hacking instead
of clean-ness, in particular the GridCoverageRenderer
has been copied over to GeoServer to make it easier to experiment.
And oh, the patch targets GeoServer trunk.
I don't have numbers coming for the 4-core OSGEO server this
time, only a quick comparison on my local dual core desktop
running the FOSS4G 2009 ECW benchmark:
Threads 1 10 20 40
gs 2.0.1 7.7 13.3 13.0 12.5
gs 2.1fcp 11.0 18.8 18.0 17.6
Simone also handed me an improved imageio-ext based on GDAL 1.6
that can deliver response rates up to 20r/s thought it is still
has stability issues and throws exceptions in around 50 responses
out of 1500 (due to the load, stand alone the same requests work fine).
What am I looking forward to? Well I hope developers with
a trunk checkout and interest in coverages try this out and help
shake a few more bugs 
Once we're satisfied with the improvements we can start adding
this path as an option in 2.0.x, to be enabled with a env
variable, thus start gathering more feedback from the user base.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
(attachments)
coverageSpeedup.patch (65.1 KB)
I (briefly) tried the patch against ArcSDE rasters and it seems to make for a _terrific_ slow down. Not sure why though.
I'll take a deeper look when I get a chance.
Cheers,
Gabriel
Andrea Aime wrote:
Hi,
this mail contains an updated patch to speed up coverage
rendering that me and Simone have been developing in our
spare time.
The patch works in a wider number of cases compared to the
original one posted in December, yet it still fails to
render images properly under some conditions.
It still targets the single raster case, if there is anything
more in the map context the normal rendering path will be used
instead.
It should work fine with RGB, RGBA and indexed color
inputs thought, and should be always returning results with
the proper size.
The patch is also still favouring ease of hacking instead
of clean-ness, in particular the GridCoverageRenderer
has been copied over to GeoServer to make it easier to experiment.
And oh, the patch targets GeoServer trunk.
I don't have numbers coming for the 4-core OSGEO server this
time, only a quick comparison on my local dual core desktop
running the FOSS4G 2009 ECW benchmark:
Threads 1 10 20 40
gs 2.0.1 7.7 13.3 13.0 12.5
gs 2.1fcp 11.0 18.8 18.0 17.6
Simone also handed me an improved imageio-ext based on GDAL 1.6
that can deliver response rates up to 20r/s thought it is still
has stability issues and throws exceptions in around 50 responses
out of 1500 (due to the load, stand alone the same requests work fine).
What am I looking forward to? Well I hope developers with
a trunk checkout and interest in coverages try this out and help
shake a few more bugs
Once we're satisfied with the improvements we can start adding
this path as an option in 2.0.x, to be enabled with a env
variable, thus start gathering more feedback from the user base.
Cheers
Andrea
------------------------------------------------------------------------
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ciao Gabriel,
this is quite strange, I have not investigated ArcSDE raster lately
but I don't really see how the patch should make things slower than
before.
I tried with geotiff, ecw, and mrsid and things were incredibly faster
( I might measure things this week). I will test more soon, but i
tmiht be worth getting some more info about how you load your data.
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
On Mon, Jan 18, 2010 at 2:41 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
I (briefly) tried the patch against ArcSDE rasters and it seems to make
for a _terrific_ slow down. Not sure why though.
I'll take a deeper look when I get a chance.
Cheers,
Gabriel
Andrea Aime wrote:
Hi,
this mail contains an updated patch to speed up coverage
rendering that me and Simone have been developing in our
spare time.
The patch works in a wider number of cases compared to the
original one posted in December, yet it still fails to
render images properly under some conditions.
It still targets the single raster case, if there is anything
more in the map context the normal rendering path will be used
instead.
It should work fine with RGB, RGBA and indexed color
inputs thought, and should be always returning results with
the proper size.
The patch is also still favouring ease of hacking instead
of clean-ness, in particular the GridCoverageRenderer
has been copied over to GeoServer to make it easier to experiment.
And oh, the patch targets GeoServer trunk.
I don't have numbers coming for the 4-core OSGEO server this
time, only a quick comparison on my local dual core desktop
running the FOSS4G 2009 ECW benchmark:
Threads 1 10 20 40
gs 2.0.1 7.7 13.3 13.0 12.5
gs 2.1fcp 11.0 18.8 18.0 17.6
Simone also handed me an improved imageio-ext based on GDAL 1.6
that can deliver response rates up to 20r/s thought it is still
has stability issues and throws exceptions in around 50 responses
out of 1500 (due to the load, stand alone the same requests work fine).
What am I looking forward to? Well I hope developers with
a trunk checkout and interest in coverages try this out and help
shake a few more bugs
Once we're satisfied with the improvements we can start adding
this path as an option in 2.0.x, to be enabled with a env
variable, thus start gathering more feedback from the user base.
Cheers
Andrea
------------------------------------------------------------------------
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
In order to support JAI deferred tiling model for ArcSDE rasters, RenderedImage returned is a crop over a custom PlanarImage (ArcSDEPlanarImage).
That is because if using a custom ImageInputStream wrapped by a RawImageInputStream, the amount of calls to seek(long pos) makes it very difficult to provide good performance (we're reading tiles sequentially out of a sort of database query).
Instead, the calls to PlanarImage.getTile(x, y) happen to be way more consistent (sequentially speaking) making of a very good performance _most_ of the time even for big images, as a single database query is performed.
That said, a call to ArcSDEGridCoverageReader.read is unlikely to return exactly the bbox/dimension requested. It'll always return the closest possible at the chosen pyramid level.
Not sure what of that might be relevant, but perhaps something rings a bell to you?
Cheers,
Gabriel
Simone Giannecchini wrote:
Ciao Gabriel,
this is quite strange, I have not investigated ArcSDE raster lately
but I don't really see how the patch should make things slower than
before.
I tried with geotiff, ecw, and mrsid and things were incredibly faster
( I might measure things this week). I will test more soon, but i
tmiht be worth getting some more info about how you load your data.
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
On Mon, Jan 18, 2010 at 2:41 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
I (briefly) tried the patch against ArcSDE rasters and it seems to make
for a _terrific_ slow down. Not sure why though.
I'll take a deeper look when I get a chance.
Cheers,
Gabriel
Andrea Aime wrote:
Hi,
this mail contains an updated patch to speed up coverage
rendering that me and Simone have been developing in our
spare time.
The patch works in a wider number of cases compared to the
original one posted in December, yet it still fails to
render images properly under some conditions.
It still targets the single raster case, if there is anything
more in the map context the normal rendering path will be used
instead.
It should work fine with RGB, RGBA and indexed color
inputs thought, and should be always returning results with
the proper size.
The patch is also still favouring ease of hacking instead
of clean-ness, in particular the GridCoverageRenderer
has been copied over to GeoServer to make it easier to experiment.
And oh, the patch targets GeoServer trunk.
I don't have numbers coming for the 4-core OSGEO server this
time, only a quick comparison on my local dual core desktop
running the FOSS4G 2009 ECW benchmark:
Threads 1 10 20 40
gs 2.0.1 7.7 13.3 13.0 12.5
gs 2.1fcp 11.0 18.8 18.0 17.6
Simone also handed me an improved imageio-ext based on GDAL 1.6
that can deliver response rates up to 20r/s thought it is still
has stability issues and throws exceptions in around 50 responses
out of 1500 (due to the load, stand alone the same requests work fine).
What am I looking forward to? Well I hope developers with
a trunk checkout and interest in coverages try this out and help
shake a few more bugs
Once we're satisfied with the improvements we can start adding
this path as an option in 2.0.x, to be enabled with a env
variable, thus start gathering more feedback from the user base.
Cheers
Andrea
------------------------------------------------------------------------
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Gabriel Roldan ha scritto:
Not sure what of that might be relevant, but perhaps something rings a bell to you?
It does not. Let's try it the other way. The proposed path chains a few
more JAI operations after the first image is rendered, this should result in more usage of the JAI tile cache (how much more, don't know).
What if you push up the size of the JAI tile cache? Does that make
things better for you?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
Gabriel Roldan ha scritto:
Not sure what of that might be relevant, but perhaps something rings a bell to you?
It does not. Let's try it the other way. The proposed path chains a few
more JAI operations after the first image is rendered,
rendered -> created by the grid coverage renderer, but not actually rendered. I'm referring to the image that the old path would have
drawn on top of the graphics2d
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.