here's just a collection of potential approaches to speed up the performance of mapping.
Before you invest resources (manpower or money) in any of these approaches feel free to get in touch with PTV consulting to evaluate the potential benefit: not every approach is meaningful for every usecase! (e.g. caching works fine with REST based approaches but not if you call native tiles based on lat-lon-coordinates)
Furthermore we have to distiguish between the following topics:- Behaviour: Environment handles each and every mapping request but is responding extremely slow. HTTP status is 200 but the tracked processing time is poor. Countermeasure: ensure proper scaling and sufficient hardware, look into server logs whether massive queueing occurs.
- Behaviour: Environment (backend servers) does reject requests due to overload (check the Exceptions for more details, especially the error codes which depends on the used protocol). Countermeasure: ensure proper scaling and sufficient hardware, look into server logs whether massive queueing occurs.
- Behaviour: Finally customers sometimes run into an issue which they perceive as "performance issue" but in fact it is a configuration error which leads to a correct denial, e.g. due to security reasons (e.g. "has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource." does not mean the server is overloaded but due to some security settings the failed response is proper). Countermeasure: ensure proper settings (Server Configuration, Webservice Interface Principles)
- configuration of xServer: get in touch with consulting to have a close look at your installation
- software: means you need a third party software
- hardware:means you need more physical resources
- business logic: means to implement an optimal workflow within the client application
| Approach | Level | Description |
|---|---|---|
| Poolsize | conf | Increase the available module count in the xserver.conf. This will not speed up a single transaction but the throughput of tiles can increase if you use the available cores of your server. |
| Tile cache (backend) | soft | Write a backend plugin in your xmap Server that caches tiles |
| Tile cache (middleware) | soft | Use a tiled map cache server, e.g. apache, reddis |
| Tile cache (framework) | soft | Use a tiled map cache plugin in your mapping framework e.g. for leaflet (e.g. maze map) or open layers |
| Reduce detail | conf | decrease the detail levels in the render ini files. Be aware that this also causes a reduction of outpout information. |
| More memory | hardware | add more memory |
| Reduce Featurelayer | app | Don't display feature layers if you don't need them |
| use cloud instead | license | xServer INTERNET applies some of the approaches so you can immediately benefit from them |
| Tile size | app | increase the size of the tiles from 256 to 512 or from 512 to 1024 |
| Parallel threads | app | use a framework that requests tiles in parallel. Be aware that some frameworks do dont accept several parallel calls to equal backend urls to prevent the risk of DDOS. |
| Disable Logging | conf | Believe it or not: too much logging info (e.g. logRequests/LogResponses and engine logs) wastes time, too |
Bernd
