Speeding up PostGIS WMS
I found that drawing data from postgis was way too slow. I needed to be
sped up to be twice as fast. I've accomplished this. Here's the changes:
1. get spatial data from postgis in base64 instead of octal
This was only 2 lines difference and was definately the best
bang-for-your buck. This was a savings of about 15%. Its significantly
more if your database isnt on the same machine as your Geoserver (it
moves about 1/3 the data).
2. I optimized the base64->byte[] function
3. I standardized the postgis driver on LiteCoordiateSequences. They
store your data in a single array of double[]. I moved the
implementation from renderer to main
(org.geotools.util.LiteCoordiateSequence[Factory]). This is faster for
most commmon operations. If you're going to be doing A LOT of JTS
functions with the geometry, you might want to convert them to
CoordinateArraySequence.
4. I moved to the JTS 1.7 WKB reader
5. I rewrote the JTS 1.7 WKB reader so it was optimized for
byte[]/2d/Big Endian. The postgis driver always requests WKB with
force_2d(asBinary(the_geom,'XDR')) so this is always the case.
6. I changed the JDBCFeatureReader to use a fetch size of 1000 (up from
200). In general, the larger this number the faster it goes (but it
uses more memory). I originally wanted it to sample features (to see how
much memory they took up) and then up the fetch size if they were
'small'. Unfortunatly, there's no easy way to determine the approximate
size of an object in java (especially in a multi-threaded environment).
7. I rewrote the renderer LineIterator. Its not much simplier and easier
to understand! I didnt rewrite the polygon, point, or collectin
iterators -- this is a future speed up for someone to do.
8. I changed the decimator so it now does decimate-in-original-CRS,
transform to screen coordinates, decimate-in-screen-coordinates in one step.
9. I found a few bugs in how filters were evaluated, which I fixed.
The only real changes were the decimator/lineiterator changes.
Currently, the biggest bottlenecks are:
1. converting byte[] to double[]. This is a trivial memmove() in most
languages, but its god-awful slow in Java. There's a native method to do
this in ObjectInputStream, but its difficult to access and for my test
data the overhead in using it was larger than the savings. Perhaps if
you have a lot of point then it would be faster. A native method would
be MUCH MUCH faster.
2. actual drawing speed
3. reading from the DB (its possible that threading the rowset fetching
could make things faster, but its possible)
I'll be commit this to 2.2.x and trunk when I've done a bit more testing.
dave
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
