Enterprise class deployment for GeoServer and GeoWebcache Optimizing performances and robustness

Enterprise class deployment for GeoServer and GeoWebcache Optimizing performances and robustness

Ing. Mauro Bartolomeoli, GeoSolutions

Ing. Andrea Aime, GeoSolutions Ing. Simone Giannecchini, GeoSolutions

FOSS4G-EU 2015, Como 14th July 2015

GeoSolutions

Italian SME

Expertise • Image Processing, GeoSpatial Data Fusion

• Java, Java Enterprise, C++, Python

• JPEG2000, JPIP, Advanced 2D visualization

Supporting/Developing FOSS4G

MapStore, GeoServer

GeoNetwork, GeoCollect

Clients

Public Agencies

Private Companies

http://www.geo-solutions.it


http://www.geo-solutions.it/



Outline

Intro to GeoServer (Optional)

Benchmarking with JMeter

Preparing raster and vector data

Optimizing styling

Output tuning

Tiling and caching

Configuring for Robustness

Deploy configurations


GeoServer

GeoServer

GeoSpatial enterprise gateway Java Enterprise

Management and Dissemination of

raster and vector data

Standards compliant OGC WCS 1.0, 1.1.1 (RI), 2.0.1

OGC WFS 1.0, 1.1 (RI), 2.0

OGC WMS 1.1.1, 1.3

OGC WPS 1.0.0

Google Earth/Maps support

KML, GeoSearch, etc..


Fo

rmats

an

d P

roto

co

ls

Ge

oS

erv

er

WFS 1.0, 1.1,

2.0

WMS 1.1.1 1.3.0

PostGIS Oracle H2 DB2 SQL Server MySql Spatialite GeoCouch

Shapefile

---------- ---------- --------- ----------

---------- ---------- --------- ----------

---------- ---------- --------- ----------

ArcSDE WFS

PNG, GIF JPEG TIFF, GeoTIFF SVG, PDF KML/KMZ

Shapefile GML2 GML3 GeoRSS GeoJSON CSV/XLS

Raw vector data

Servers

Styled maps

DBMS

Vector files

WCS 1.0,1.1.1

2.0.1 GeoTIFF WMS ArcGrid GTopo30 Img+world Mosaic MrSID JPEG 2000 ECW,Pyramid, Oracle GeoRaster, PostGis Raster, NetCDF

Raster files

Raw raster data

GeoTIFF ArcGrid GTopo30 Img+World

GWC (WMTS,

TMS, WMS-C)

KML superoverlays Google maps tiles OGC tiles OSGEO tiles

Google

WPS 1.0.0


Intro to GeoServer

In case you are not that familiar with it (fool!) GeoServer Release Schedule

http://geoserver.geo-solutions.it/edu/en/install_run/releases.html

Web Administration Interface http://geoserver.geo-solutions.it/edu/en/install_run/wai.html

GeoServer Data Directory http://geoserver.geo-solutions.it/edu/en/adding_data/structure.html

Adding a Shapefile http://geoserver.geo-solutions.it/edu/en/adding_data/add_shp.html

Adding a Postgis layer http://geoserver.geo-solutions.it/edu/en/adding_data/postgis_lay.html

Adding a GeoTiff http://geoserver.geo-solutions.it/edu/en/adding_data/add_geotiff.html

Adding a Style http://geoserver.geo-solutions.it/edu/en/pretty_maps/add_style.html





http://geoserver.geo-solutions.it/edu/en/install_run/wai.html



http://geoserver.geo-solutions.it/edu/en/adding_data/structure.html



http://geoserver.geo-solutions.it/edu/en/adding_data/add_shp.html



http://geoserver.geo-solutions.it/edu/en/adding_data/postgis_lay.html



http://geoserver.geo-solutions.it/edu/en/adding_data/add_geotiff.html



http://geoserver.geo-solutions.it/edu/en/pretty_maps/add_style.html



Benchmarking with JMeter

Benchmarking

Benchmarking is an important phase in project development

It gives you various information about your application:

Scalability issues

Robustness in extreme conditions

Presence of any bottleneck inside the application

Performances Test against another software


Local Testing vs Remote Testing

Network sometimes can compromise the results of your tests

In case of high network overload you may see low throughput

This can be associated to a bottleneck of the connection which results in bad performances without concerning about the request type

For this reason, be careful to setup your remote tests in a separate network in order to avoid network overload

FOSS4G-EU 2015, Como

14th July 2015

Lookout for the bottleneck

Typical bottlenecks:

CPU: at high load all the CPUs are pegged

Disk: CPUs are not hot, the server is reading a lot from the disk during the benchmark

Network (data sources): CPUs are not hot, but the local network (maybe towards the DB) is at full capacity

Network (output): all local resources are midly used, but the outbound connection is at full capacity

Code scalability: none of the above, every resource seems to be in light use and usage is not going up despire higher client load


Introduction to JMeter

Open Source performance measurement tool written in Java

This tool will be highly used during the workshop for testing the GeoServer performances against Benchmark data

More informations can be found at the Jmeter site:

http://jakarta.apache.org/jmeter/


Introduction to JMeter

Easy-to-use UI

Allows to setup multiple thread groups, different parallelism and request count, to ramp up the load

Can use CSV files to generate semi-randomized requests

Can execute parameterized tests

Reports results in a simple table

Uses Assertions for checking test results

Can be executed in batch


Using JMeter

Thread group: how many threads

Loop: how many requests

HTTP sampler: the request

CSV: read request params from CSV

Default: do not repeat what’s equal in all requests

Performance summary


Result Summary

Results table

Run the benchmarks 2-3 times, let the results stabilize

Save the results, check other optimizations, compare the results


Exercise

Let's start with practice!!!

Follow the instructions on the link below

http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_simple.html

You should be able to reproduce the test using the GeoServer Training instance installed in your PC

This simple exercise will show you how to use JMeter with a basic configuration for testing GeoServer performances


Randomized Multiscale Testing

In the example before, we ran a test on a layer always setting the same bounding box and image size

Now we should setup a more complicated test asking for different bounding boxes and resolutions, aka Multiscale testing

Multiscale testing is useful because it stresses GeoServer requesting new data each time, mimicking real usage conditions and providing better testing for your SLD scale dependencies

With JMeter we can execute the test by passing a CSV file containing multiple bounding boxes and image dimensions


Exercise

Multiscale test created using wms_request.py on a mosaic layer

Follow the instructions on the link below

http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_multiscale.html

This exercise will show you how to use create a CSV file containing requests at multiple resolutions and how to run JMeter with it


Preparing Raster Inputs

Intro to GDAL Utilities

Online Material http://geoserver.geo-

solutions.it/edu/en/raster_data/processing.html

http://www.gdal.org/gdal_utilities.html


http://geoserver.geo-solutions.it/edu/en/raster_data/processing.html




http://www.gdal.org/gdal_utilities.html

Raster Data CheckList

Objectives

Fast extraction of a subset of the data

Fast extraction of the desired resolution

Check-list

Avoid having to open a large number of files per request

Avoid parsing of complex structures and slow compressions

Get to know your bottlenecks

CPU vs Disk Access Time vs Memory

Experiment with

Format, compression, different color models, tile size, overviews, GeoServer configuration


Peculiar Formats

PNG/JPEG direct serving (as data sources)

Bad formats (especially in Java)

No tiling (or rarely supported)

Chew a lot of memory and CPU for decompression

Mitigate with external overviews

Any input ASCII format (GML grid, ASCII grid)

JPEG2000

Extensible and rich, not (always) fast, can be difficult to tune for performance (might require specific encoding options)

MrSID (can work, needs tuning)

ECW (licensing issues)


GeoTiff for the win

To remember: GeoTiff is a swiss knife

But you don’t want to cut a tree with it!

Tremendously flexible, good for for most (not all) use cases

BigTiff pushes the GeoTiff limits farther

Use GeoTiff when

Overviews and Tiling stay within 4GB

No additional dimensions

Consider BigTiff for very large file (> 4 GB)

Support for tiling

Support for Overviews

Can be inefficient with very large files + small tiling


GeoTiff preparation

(Optional) Use gdal_warp to transform the data in the most used output reference system (mind, any reprojection ruins the data a bit)

Use gdal_translate to add inner tiling and fix eventual issues with coordinate reference system

Add compression options if you disks are small/slow/not local (consider JPEG compression with YCBCR color interpretation for photos, LZW/Deflate for scientific data)

Use gdaladdo to add internal overviews (remember to replicate compression here)


Possible structures

Single GeoTiff with internal tiling and overviews (GeoTiff < 2GB, BigTiff < 20-50GB)

Mosaic of GeoTiff, each one with internal tiling and overviews (< 500GB, not too many files)

Image pyramid, each level has lower resolution than the previous, each level has tiles with inner tiling but no overviews (also possible to mix, less levels and use internal overviews) > 500GB


Choosing Formats and Layouts

Use ImageMosaic when:

A single file gets too big (inefficient seeks, too much metadata to read, etc..)

Multiple Dimensions (time, elevation, others..)

Avoid mosaics made of many very small files

Single granules can be large

Use Tiling + Overviews + Compression on granules

Use ImagePyramid when:

Tremendously large dataset

Too many files / too large files

Need to serve at all scales

Especially low resolution

For single granules (< 2Gb) GeoTiff is generally a good fit


Proper Mosaic Preparation

Optimize files as if you were serving them individually

Keep a balance between number and dimensions of granules

If memory is scarce: USE_JAI_IMAGREAD to true USE_MULTITHREADING to false*

Otherwise USE_JAI_IMAGREAD to false ALLOW_MULTITHREADING to true

(Load data from different granules in parallel)

More Info http://geoserver.geo-

solutions.it/edu/en/raster_data/mosaic_pyramid.html


http://geoserver.geo-solutions.it/edu/en/raster_data/mosaic_pyramid.html




Proper Pyramid Preparation

Use gdal_retile for creating the pyramid Prepare the list of tiles to be retiled

Create the pyramid with GDAL retile (grab a coffee!)

Chunks should not be too small (here 2048x2048), if you go larger, use also inner tiling

If the input dataset is huge use the useDirForEachRow option Too many files in a dir is bad practice

Make sure the number of level is consistent with usage Too few bad performance at high scale

GeoServer config same as mosaic More Info

http://geoserver.geo-

solutions.it/edu/en/raster_data/mosaic_pyramid.html


http://www.gdal.org/gdal_retile.html




Proper GeoServer Coverage Config Opts

Make sure native JAI is installed

Install the TurboJPEG extension

Enable JAI Mosaicking native acceleration

Give JAI enough memory

Don’t raise JAI memory Threshold too high

Rule of thumb: use 2 X #Core Tile Threads (check next slide)

Play with tile Recycling against your workflows (might help, might not)


Proper GeoServer Coverage Config Opts

Multithreaded Granule Loading

Allows to fine tuning multithreading for ImageMosaic

Orthogonal to JAI Tile Threads

Rule of Thumb: use 2 X #Core Tile Threads

Perform testing to fine tune depending on layer configuration as well as on typical requests

ImageIO Cache threshold

decide when we switch to disk cache (very large WCS requests)


Exercise

Let's check the effect of optimization in GeoServer

Follow the instructions on the links below

http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_mosaic.html

This test uses JMeter for testing GeoServer performances before and after the optimization of a Mosaic Layer.


Additional Material & Exercises

Using ImageMosaic with Footprint

http://geoserver.geo-solutions.it/edu/en/raster_data/imagemosaic_footprint.html

Advanced Processing With GDAL Utilities

http://geoserver.geo-solutions.it/edu/en/raster_data/advanced_gdal/index.html








Preparing vector inputs

Vector data checklist

What do we want from vector data:

Binary data

No complex parsing of data structures

Fast extraction of a geographic subset

Fast filtering on the most commonly used attributes


Choosing a format

Slow formats

WFS

GML

DXF

Good formats, local and index-able

Shapefile

Directory of shapefiles

SDE

Spatial databases: PostGIS, Oracle Spatial, DB2, MySQL*, SQL server*

Swiss Knife SQL Views


DBMS Checklist

Rich support for complex native filters

Use connection pooling

Validate connections (with proper pooling)

Table Clustering

Spatial Indexing

Spatial Indexing

Spatial Indexing

Alphanumeric Indexing



Did we mention indexes?


Shapefile preparation

Remove .qix file if present

If there are large DBF attributes that are not in use, get rid of them using ogr2ogr, e.g.: ogr2ogr -select FULLNAME,MTFCC arealm.shp tl_2010_08013_arealm.shp

If on Linux, enable memory mapping, faster, more scalable (but will kill Windows):


Shapefile filtering

Stuck with shapefiles and have scale dependent rules like the following?

Show highways first

Show all streets when zoomed in

Use ogr2ogr to build two shapefiles, one with just the highways, one with everything, and build two layers, e.g.: ogr2ogr -sql "SELECT * FROM

tl_2010_08013_roads WHERE MTFCC in ('S1100',

'S1200')" primaryRoads.shp

tl_2010_08013_roads.shp

Or hire us to develop non-spatial indexing for shapefile!


PostGIS specific hints

PostgreSQL out of the box configured for very small hardware: http://wiki.postgresql.org/wiki/Performance_Optimization

Make sure to run ANALYZE after data imports (updates optimizer stats)

As usual, avoid large joins in SQL views, consider materialized views

If the dataset is massive, CLUSTER on the spatial index:

http://postgis.refractions.net/documentation/manual-1.3/ch05.html


http://wiki.postgresql.org/wiki/Performance_Optimization




PostGIS specific hints

Careful with prepared statements (bad performances)

USE CASE: the layer’s style allows to display the whole layer in a single shot (no scale dependencies) prepared statements will slow down execution

EXPLANATION: Postgis will choose to use the spatial index in all cases, this makes retrieving the full data set 2-4 times slower than when using a sequential scan

COUNTERMEASURE: Not using prepared statement allows postgis to figure out a suitable plan based on the request bbox instead (assuming someone run "vacuum analyze" on the database to update the index statistics, and of course, provided there is a spatial index to start with)


SQL Server specific hints

Switch to PostgreSQL/PostGIS!


Oracle specific hints

Switch to PostgreSQL/PostGIS!


SQL Views Support

Vector Data Swiss Knife

http://geoserver.geo-solutions.it/edu/en/adding_data/add_sqllayers.html






Exercise

Let's compare Shapefile and PostGIS in GeoServer


http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_vector.html

This test uses Jmeter for comparing GeoServer performances using a Shapefile or an optimized PostGIS database containing the same data


Optimize styling

Use scale dependencies

Never show too much data

the map should be readable, not a graphic blob. Rule of thumb: 1000 features max in the display, have labels show up when zoomed in

Show details as you zoom in

Eagerly add MinScaleDenominator to your SLD rules

Add more expensive rendering when there are less features

Key to get both a good looking and fast map


Example


Labeling

Labeling conflict resolution is expensive, limit to the most inner zooms

Halo is important for readability, but adds significant overhead

Careful with maxDisplacement, makes for various label location attempts


FeatureTypeStyle

GeoServer uses SLD FeatureTypeStyle objects as Z layers for painting

Each one allocates its own rendering surface (which can use a lot of memory), use as few as possible


Use translucency sparingly

Translucent display is expensive, use it sparingly

e.g. translucent fill <CssParameter name="fill-opacity">0.5</CssParameter>


Exercise

Let's compare bad styles with properly setup ones


http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_styles.html

This test uses JMeter to compare a style without scale dependencies, showing too much data and too many labels, with a one with proper scale dependencies and providing a better looking output at the same output


Tiling & Caching

Tile caching with GeoWebCache

Tile oriented maps, fixed zoom levels and fixed grid

Useful for stable layers, backgrounds

Protocols: WMTS, TMS, WMS-C, Google Maps/Earth, VE

Speedup compared to dynamic WMS: 10 to 100 times, assuming tiles are already cached (whole layer pre-seeded)

Suitable for:

Mostly static layer

No/few dynamic parameters (CQL filters, SLD params, SQL query params, time/elevation, format options)


Embedded GWC advantage

No double encoding when using meta-tiling, faster seeding


Space considerations

Seeding Colorado, assuming 8 cores, one layer, 0.1 sec 756x756 metatile, 15KB for each tile

Do yours: http://tinyurl.com/3apkpss

Not enough disk space? Set a disk quota

Zoom

level Tile count Size (MB)

Time to seed

(hours)

Time to seed

(days)

13 58,377 1 0 0

14 232,870 4 0 0

15 929,475 14 0 0

16 3,713,893 57 1 0

17 14,855,572 227 6 0

18 59,396,070 906 23 1

19 237,584,280 3,625 92 4

20 950,273,037 14,500 367 15


http://tinyurl.com/3apkpss

http://tinyurl.com/3apkpss

DiskQuota

Online Material

http://geoserver.geo-solutions.it/edu/en/caching_data/diskquotas.html#disk-quota-configuration











More Tweaks

REST Interface Automate/Script management

Truncate

Remove Cached tiles

Seed

Pre-generate cache

Reseed

Regenerate tiles (due to data update, for instance)

Every seed/truncate operation can be filtered by:

Bounding box / Zoom limits

/ Format / GridSet

Parameters (style, time, other dimensions, cql_filter…)

Thread number


More Tweaks

REST Seed example


curl -u admin:password -H 'Content-type: text/xml' -H 'Accept: text/xml' -XPOST -d ' <seedRequest> <name>topp:states</name> <type>seed</type> <gridSetId>EPSG:4326</gridSetId> <bounds> <coords> <double>-100</double><double>-80</double><double>100</double><double>80</double> </coords> </bounds> <zoomStart>0</zoomStart><zoomStop>8</zoomStop> <format>image/png8</format> <threadCount>04</threadCount> <parameters> <entry> <string>CQL_FILTER</string> <string>TOTPOP BETWEEN 0 AND 10000</string> </entry> </parameters> </seedRequest> ' http://localhost:8080/geoserver/gwc/rest/seed/topp:states.xml

More Tweaks

Online Resources for GWC REST API

Documentation

http://geowebcache.org/docs/current/rest/seed.html

http://docs.geoserver.org/stable/en/user/geowebcache/rest/seed.html

Bash script for seed/reseed/truncate/mass truncate operations

https://github.com/geosolutions-it/scripts/blob/master/geowebcache/gwc.sh

Sample script for clean cache in geoserver cluster

https://github.com/geosolutions-it/scripts/blob/master/geowebcache/cleancache.sh















More Tweaks

Clustering Single Shared Cache

Large, shared disk with fast R/W access

Perfect for bkg layers

Problematic set up in public cloud

Clustering Multiple Indipendent Caches

Exploit local, small, instance-based caches

Good for short lived caches

Duplication hit rsynch can help

Real-World Use Case

Dedicated Instances with shared cache for Bkg Layers

Indipendent Caches for other layers


More Tweaks

Client-side caching of tiles

Does not work with browsers in private mode

<expireClientsList> <expirationRule minZoom="0" expiration="7200" /> <expirationRule minZoom="10" expiration="600" /> </expireClientsList>


More Tweaks

Use the right formats

JPEG for background data (e.g. ortos)

PNG8 + precomputed palette for background data (e.g. ortos)

PNG8 full for overlays with transparency

The format impacts also the disk space needed! (as well as the generation time)

Check this blog post


http://geo-solutions.blogspot.co.uk/2012/05/tips-tricks-geowebcache-tweaks.html

Exercise

Let's compare GeoServer WMS with GeoWebCache fullWMS.


http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_gwc.html

This test uses JMeter for comparing GeoServer WMS performances against those of GeoWebCache fullWMS

Mind, this is not the same as comparing WMS with pure tile caching, GWC has to read the tiles from disk, decompress, assemble the output image, and compress it again in PNG (some speedup still, but not 10 times)


Advanced GeoServer Configuration

Resource Limits

Limit the amount of resources dedicated to an individual request

Improve fairness between requests, by preventing individual requests from hijacking the server and/or running for a very long time

EXTREMELY IMPORTANT in production environment

WHEN TO TWEAK THEM?

Frequent OOM Errors despite plenty of RAM

Requests that keep running for a long time (e.g. CPU usage peaks even if no requests are being sent)

DB Connection being killed by the DBMS while in usage (ok, you might also need to talk to the DBA..)


WMS request limits

Max memory per request: avoid large requests, allows to size the server memory (max concurrent request * max memory)

Max time per request: avoid requests taking too much time (e.g., using a custom style provided with dynamic SLD in the request)

Max errors: best effort renderer, but handling errors takes time


WFS request limits

Max feature returned, configured as a global limit

Return feature bbox: reduce amount of generated GML

Per layer max feature count


WCS request limits


Exercise

Let's show how resource limits can be used to avoid issues with slow requests


http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_wmslimits.html

This test artificially limits the database resources to quickly generate a starvation situation in which the limits kick-in


Control flow

Control how many requests are executed in parallel, queue others:

Increase throughput

Control memory usage

Enforce fairness

More info

http://docs.geoserver.org/latest/en/user/community/controlflow/index.html




$GEOSERVER_DATA_DIR/controlflow.properties

# don't allow more than 16 GetMap requests in parallel

ows.wms.getmap=16

Control flow

17%


Resource Limits

They need to be tweaked together with Control- Flow

Limiting individual requests Resource Limits

Limiting amount of parallel request Control Flow

When time is involved make sure you keep into account all pieces of the response chain

E.G. Limited rendering time for WMS on data coming from WMS, items to take into account are

LifeTime of DB Connection (usually long)

WaitTime for a new connection (we don’t want to queue requests at the connection pool when they area already eating memory!)

FOSS4G-EU 2015, Como

14th July 2015

Connection Pooling Tricks

Connection pool size should be proportional to the number of concurrent requests you want to serve (obvious no?)

Activate connection validation

Mind networking tools that might cut connections sitting idle (yes, your server is not always busy), they might cut the connection in “bad” ways (10 minutes timeout before the pool realizes the TCP connection attempt gives up)

Read more at

http://geoserver.geo-solutions.it/edu/en/adv_gsconfig/db_pooling.html

https://docs.google.com/document/d/1O02PeDRYKt2xLWG21k6BmcaRPzVRvXb4SQcrcZf4bHQ/edit?usp=sharing










Exercise

Let's show how control-flow works in GeoServer


http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_controlflow.html

This test uses JMeter for testing GeoServer performances before and after configuring the control-flow plugin.


JVM and deploy configuration

Premise

The options discussed here are not going to help visibly if you did not prepare the data and the styles

They are finishing touches that can get performance up once the major data bottlenecks have been dealt with

Check “Running in production” instructions here


http://docs.geoserver.org/latest/en/user/production/index.html

JVM settings

--server: enables the server JIT compiler

--Xms2048m -Xmx2048m: sets the JVM use two gigabytes of memory

--XX:+UseParallelOldGC -XX:+UserParallelGC: enables multi-threaded garbage collections, useful if you have more than two cores

--XX:NewRatio=2: informs the JVM there will be a high number of short lived objects

--XX:+AggressiveOpt: enable experimental optimizations that will be defaults in future versions of the JVM


Setup a local cluster

Oracle Java2D locks when drawing antialiased vectors

Limits scalability severely

Two options

Use OpenJDK, it’s slower at rendering but scales up well

Use Apache mod_proxy_balance and setup a GeoServer each 2/4 cores

mod_proxy_balance

GeoServer GeoServer GeoServer


Clustering advantage

66%

FOSS4G 2010 vector benchmarks (roads/buildings/isolines and so on, over the entire Spain)

GeoServer was benchmarked using Oracle JDK without local clustering


Marlin renderer

The OpenJDK Java2D renderer scales up, but it’s not super-fast when the load is small (1 request at a time)

Marlin-renderer to the rescue: https://github.com/bourgesl/marlin-renderer

Complex map, 10 parallel requests, different zoom levels have different details showing up


Upgrade!

Performance tends to go up version by version

Please do use a recent GeoServer version

FOSS4G 2010 vector benchmark with different versions of GeoServer


Exercise

Let's show how Marlin renderer can speed up map rendering under Windows, using GeoServer 2.5.x


http://geoserver.geo-solutions.it/educational/en/adv_gsconfig/jmeter/jmeter_marlin.html

This test uses JMeter for testing GeoServer performances before and after setting up Marlin renderer


Clustering

Clustering with GeoServer

Online Material

http://geoserver.geo-solutions.it/edu/en/clustering/index.html





The End

Questions? [email protected]


Enterprise class deployment for GeoServer and GeoWebcache Optimizing performances and robustness

Technology

Transcript of Enterprise class deployment for GeoServer and GeoWebcache Optimizing performances and robustness