Hi,
last week in my research on how to make a parallel (-T2C) build faster I
made
the hyphotesis that having WMS not depend anymore on WFS would have sped
up the build... this week I've made some experiments to see if that is true.
The WMS module depends on the WFS one from a few points of view:
- the JSON output handling is in the WFS output module
- the GML2 output handling is in the WFS output module
- the GML3 output handling is in the WFS output module
- some KVP parsers needed for a WMS request are declared and shared in the
WFS module
- both WMS and GWC implement TranslactionListener
The idea is to relieve WMS/GWC from their WFS dependencies by factoring out
helper objects to be put in "main" as much as possible.
As far as JSON is concerned the moves to be made were simple and clean,
just created a org.geoserver.json package in main and moved most of the JSON
handling code there, creating a JSONFeatureWriter that does the JSON writing
without having to know if it's doing so on behalf of WFS or WMS:
https://github.com/aaime/geoserver/tree/wms-untangle/src/main/src/main/java/org/geoserver/json
One annoyance present here is that the WMS JSON preferences in the current
code
are controlled by the WFS service configuration, which is wrong in my book.
In particular, the feature bounding flag comes from WFSInfo.
For the time being I've just set the feature bounding to true in
GetFeatureInfo, under the
assumption that GetFeatureInfo returns so few records that having the
feature
bounds always on is not going to cause troubles.
For GML2 things are similar, but there is even more binding between the
WFSInfo params
and the output format.
Again, for the time being I've made some static choices that do make sense
for the WMS
usage:
https://github.com/aaime/geoserver/blob/wms-untangle/src/main/src/main/java/org/geoserver/gml/GML2Writer.java
https://github.com/aaime/geoserver/blob/wms-untangle/src/wfs/src/main/java/org/geoserver/wfs/xml/GML2OutputFormat.java
https://github.com/aaime/geoserver/blob/wms-untangle/src/wms/src/main/java/org/geoserver/wms/featureinfo/GML2FeatureInfoOutputFormat.java
The GML3 case seems like a lost cause, the GML3OutputFormat is so deeply
entangled with the WFS
configuration that it seems rather hard to take it apart and make it
generic.
For the time being I've just disabled the GML3FeaturInfoOutputFormat, as it
is involved is a very limited set
of tests (just two tests in app-schema-test) and I really wanted to see
about the build time speedup.
More on this later.
The shared KVP parsers (bbox, cql, featureid, filter) have just been moved
to ows and been declared in the main
module instead.
I was temped to make two service specific parsers for each module, but
there are tests relying on the fact that
the parser is not service specific, given that declaring them in main seems
to cause no issues, I've just
let them be.
Finally, there is the TransactionListener. Looking at the API it was
evident that making a couple of simple
changes it would have been possible to make the API depend solely on the
WFS EMF model, without
any dependency towards the WFS module itself.
And so I did:
https://github.com/aaime/geoserver/tree/wms-untangle/src/main/src/main/java/org/geoserver/wfs
Now, what are the results of the change?
>From one side, a cleaner WMS module that does not have to depend on WFS.
This is better
from a modelling point of view, but also better from a practical
standpoint, but this has significant
repercussion on build times.
Why? Well, it seems that the beans declared in the WFS app context take a
while to initialize,
so the less code depends on them, the faster the build is.
With the changes I've made the build time for a full parallel build (with
extensions,
"mvn clean install -T4 -Prelease -nsu") go down from 9m30s to 8m06s.
That's quite the improvement if you ask me! :-p
Also, I'm confident this will be improved even further by the work on not
writing the configuration on disk
The full patch is here:
https://github.com/aaime/geoserver/compare/wms-untangle
If you are interested and want to help, here is what is left to be done:
* review the patch
* solve the GML3 issue.... do we really need to mimick the WFS output that
closely?
Can we, for example, just encode GML3 using the GeoTools Encoder without
that many
customizations?
* consider splitting restconfig in two, one part that deals with the
catalog, and that can build
without being dragged down by WFS, and a restconfig-services, that
contains only the
service configuration portions, which will depend on WFS and the other
services instead.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
