Hi,
Quoting the release post of geoserver 1.6beta2:
"The final major improvement is increased performance of shapefiles,
thanks to the Shapefile Renderer developed by Refractions for use in
uDig. This is a great example of the virtuous circle of open source,
where we can take advantage of their improvements. So shapefiles
should be a bit faster in this release"
We are actually noticing a performance decrease. Where flamingo
renders a map in 10 seconds with geoserver 1.5 backend, the 1.6beta2
takes 30 minutes to complete the request.
This occurs when using shapefiles. The geoserver log states many
messages like these:
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
Can we perform some more tests to check out where the delay is being
caused? Is the new shapefile renderer benchmarked against certain
filetypes/sizes?
Kind regards,
Pieter Jansen
Wow, that's bad. Any chance you can pass us the shapefile to try out ourselves? And what OS are you working on?
Thanks so much for testing, we haven't had a chance to benchmark it, and if it does end up slower we'll probably drop it. But uDig uses it by default, and has done a lot of testing with it, so we figured it would work out.
Actually, could you try to load it in uDig and see if it takes that long to load? If it doesn't then I suppose we misconfigured something in geoserver.
thanks!
Chris
Pieter Jansen wrote:
Hi,
Quoting the release post of geoserver 1.6beta2:
"The final major improvement is increased performance of shapefiles,
thanks to the Shapefile Renderer developed by Refractions for use in
uDig. This is a great example of the virtuous circle of open source,
where we can take advantage of their improvements. So shapefiles
should be a bit faster in this release"
We are actually noticing a performance decrease. Where flamingo
renders a map in 10 seconds with geoserver 1.5 backend, the 1.6beta2
takes 30 minutes to complete the request.
This occurs when using shapefiles. The geoserver log states many
messages like these:
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
Can we perform some more tests to check out where the delay is being
caused? Is the new shapefile renderer benchmarked against certain
filetypes/sizes?
Kind regards,
Pieter Jansen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:4005,46a5ddfc282901137850744!
Hi Chris,
On 7/24/07, Chris Holmes <cholmes@anonymised.com> wrote:
Wow, that's bad. Any chance you can pass us the shapefile to try out
ourselves? And what OS are you working on?
Windows XP sp1
Could it be that the new shapefile renderer generates more debugging
info, causing delays? The developer hasn't tested it without
debugging.
The developer will be back thursday. I will forward this information to him.
Also, I have placed a request for permission to send you the
shapefiles. The data-owner will be in tomorrow.
Thanks so far.
Pieter
Pieter Jansen wrote:
Hi Chris,
On 7/24/07, Chris Holmes <cholmes@anonymised.com> wrote:
Wow, that's bad. Any chance you can pass us the shapefile to try out
ourselves? And what OS are you working on?
Windows XP sp1
Could it be that the new shapefile renderer generates more debugging
info, causing delays? The developer hasn't tested it without
debugging.
Yeah, I was thinking that too. Could try just turning down the logging statements, I'd be interested in the results of that.
The developer will be back thursday. I will forward this information to him.
Also, I have placed a request for permission to send you the
shapefiles. The data-owner will be in tomorrow.
Sounds great.
best regards,
Chris
Thanks so far.
Pieter
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:4005,46a61079324451336712104!
Pieter Jansen wrote:
Hi,
Quoting the release post of geoserver 1.6beta2:
"The final major improvement is increased performance of shapefiles,
thanks to the Shapefile Renderer developed by Refractions for use in
uDig. This is a great example of the virtuous circle of open source,
where we can take advantage of their improvements. So shapefiles
should be a bit faster in this release"
We are actually noticing a performance decrease. Where flamingo
renders a map in 10 seconds with geoserver 1.5 backend, the 1.6beta2
takes 30 minutes to complete the request.
Wow!! 10 seconds -> 30 minutes... something is definitely not right here. Any chance you mean 30 seconds? That would still be bad though.
This occurs when using shapefiles. The geoserver log states many
messages like these:
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - trying to read geometry ...
2007-07-19 14:45:23,265 DEBUG [renderer.shape] - skipping geometry
Can we perform some more tests to check out where the delay is being
caused? Is the new shapefile renderer benchmarked against certain
filetypes/sizes?
Nothing formal... I think of course it is faster on smaller file sizes... but from what I know scales up nicely to larger files as well. The only other thing you could do is 1. turn down logging to see if it persists and 2. run it in a profiler.
If you are able to send the data we will do #2.
Kind regards,
Pieter Jansen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:4007,46a5ddfc282911637810514!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Eureka!
On 7/24/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Wow!! 10 seconds -> 30 minutes... something is definitely not right
here. Any chance you mean 30 seconds? That would still be bad though.
"minutes" was correct 
Nothing formal... I think of course it is faster on smaller file
sizes... but from what I know scales up nicely to larger files as well.
The only other thing you could do is 1. turn down logging to see if it
persists and 2. run it in a profiler.
Reports on #1 are just in: the new shapefile renderer is -faster- than
the old one. The new shapefile renderer actually produces more debug
information, causing big slowdowns. In production situations you will
not need the debug information, but during development this might be
unwanted.
You could try to implement the "Last message repeated N times" filter
syslog uses, or disable this debugging print.
Thanks for the help and suggestions, problem solved.
Kind regards,
Pieter