WMTS Performance Tests

WMS Performance TestsCase FMI 2014

15.04.2023 2

New User Interface

WMS Performance TestsRoope Tervo

15.04.2023 3

New User Interface


• http://ilmatieteenlaitos.fi/sadealueet-suomessa• WMTS Animation• Radar Images with a short forecast

• Area: Finland• Time range: -3 -- +2 hours• Time step: 15 minutes• 3 zoom levels

• 3 layers in total• Background map• Weather information• Foreground map

• Possibility to view in full screen• Client based on OpenLayers

• Available as open source:

https://github.com/fmidev

15.04.2023 4

Backend

• Based on GeoServers with

GeoWebCache• Setup:

• 3 physical servers

• 24 x 2.67GHz core

• 94 G RAM

• 3 instances per server

• Load balancer provides relatively

small (200 M) in-memory cache• Tiles are generated in advance with

a separate GeoServer instance • Tile cache on NFS common for

all instances

Intranet

DMZ

Load Balancer

Configuration GeoServer

Data (NFS)

Configuration (NFS)

Database

Server 1

GS1

GS2

GS3

Server 2

GS1

GS2

GS3

Server 3

GS1

GS2

GS3


15.04.2023 5

New service(Consciously) burden for backends

No knowledge about it’s popularity

Relatively new backendUsed for some time but without heavy load.

How to ensure that backend can handle the load?We don’t want it to go down, especially when the new client is released.

Clearly, we needed some performance testing.How to estimate what kind of load our backends should handle?


15.04.2023 6

Estimating Load


• Year before (17.6.2013) radar animation page had usage

peaks of almost 60 000 visitors in an hour• Information based on Google Analytics

• Assumption: in maximum, half of the visitors would like to use

the new service

15.04.2023 7

Estimating Load


• Client size is 750 x 750 px• Tile size is 256 x 256 px• No buffer around the visible area• 3 zoom levels

One layer (one time stamp) causes 27 tile requests 3*(round(750/256))2=27

15.04.2023 8

Estimating Load


• Time range: -3 -- +2 hours• Time step: 15 minutes20 time steps

• 3 layers (background, foreground and weather data image)• Background and foreground maps need to be loaded only

once

One page load causes 594 tile requests

20*27+27+27=594

15.04.2023 9

Estimating Load


• Worst case (for servers) scenario: 30 000 page loads per

hour

17 820 000 tile requests per hour

594*30000=17820000• Requests can be assumed to spread evenly to the peak hour

• Load caused by humans

• Interest to the service caused by a weather phenomenon

Estimated maximum load for backends is 5000 req/s round(594*60000/2/3600)=5000

15.04.2023 10

Estimating Load


• Even we have a relatively good estimation about usage,

there are many uncertainties left• Clients may be used in full screen mode

• The backend is also used in other applications

• Backend contains dozens of different kinds of layers• Causes very different kind of load

• Not all layers can be tiled. Cache size for one radar

layer 86 G

15.04.2023 11

Running the Tests


• We had to use the production cluster• Hard to establish test cluster in traditional environment

Other clients using GeoServers was going to suffer

We didn’t want other components (like load balancer) to go down

• Plan was to run first easy test and harden the load until we

find a limit or we reach the 5000 req/s

15.04.2023 12

Tests and Results#1 Four Layers | 2000 req/s


• Only 2/4 layers were tiled in advance• If GeoServers need to generate tile on-demand, performance

is very poor• Due to a lock in common cache folder

• Note that WMS requests without tiling perform much better

15.04.2023 13

Tests and Results#2 Two Layers | 2000 req/s


• All layers in the test were tiled in advance• All good• Load balancer responded roughly 1/2 of the requests from

the in-memory cache• GeoServers responded to about 1000 req/s

15.04.2023 14

Tests and Results#3 Two Layers | 4000 req/s


• All layers in test were tiled in advance• All good• Load balancer responded roughly 3/4 of the requests from

the in-memory cache• GeoServers responded to about 1000 req/s

15.04.2023 15

Conclusions


• Unfortunately we were unable to run any harder tests

because of limited time• No scaling issues were found in a “correct” usage scenario

• Load balancer took all extra load

• Harder tests would had stressed only the load balancer, not

GeoServers

• Still, the setup is very vulnerable for unexpected usage

scenarios• Requesting WMTS layers which are not tiled in advance

• Requesting large amount of different WMS layers

(as it prunes load-balancer’s cache)

15.04.2023 16

Conclusions


• Backend have worked well• Optimizing the client is next on the roadmap (without

compromising user experience)• Reducing requests

• Optimizing loading order

15.04.2023 17

Running performance tests is easyAnalyzing cause of problems may be harder


Date post:	04-Aug-2015
Category:	Technology
Upload:	roope-tervo
View:	151 times
Download:	1 times

WMTS Performance Tests

Technology