...
Load testing has been attempted using the package from K6.io. Output has been written to an InfluxDB database, and visualizations have been configured using Graphana. Tests can be viewed at https://dev.azure.com/TCOPP/_git/EGIS?path=%2FARM%2Floadtest&version=GBfeatures%2Floadtest%2Fk6, specifically egisloadtest.js. See the readme.md https://dev.azure.com/TCOPP/_git/EGIS?path=%2FARM%2Floadtest%2Fvm%2Freadme.md&_a=preview in that folder for details on how to run these.
With this framework in place, the performance of OIM layers and TCOMS has been evaluated.
Repeating these tests
The tests shown here are available in version control as mentioned in the overview. These tests can be run from your Windows workstation by installing the K6 Windows Binaries.
The Linux VM is only used to track and graph test results. Details on accessing or recreating this VM are contained in the readme.md file in version control.
Sandbox
Testing has been performed on the SBX instance, consisting of an Azure VM for each of the Web and Portal, GIS Server, and Data Store roles. Note that SBX is behind a firewall maintained by the cloud team, and our loadtest VM is not whitelisted to access SBX at the time of writting. All tests were performed on the TC network. The results follow:
...
GeoResources
It is assumed that GeoResources is populated by querying eGIS from the IMS server side
Active Incidents
An embedded web map showing a common operating picture
Event Details
An details page with an embedded web map
https://ncras559.tc.gc.ca:4343/en/Event/Details/2019-08-00170
| Info |
|---|
A request has been sent to the TCOMS team for feedback on performance and suggested areas for improvement. |
GeoResources
This page no longer makes references to the eGIS sandbox. The main HTML document takes around 6 seconds to load. It is assumed that calls are made to the eGIS portal on the server side. It may be a better experience to load the document quickly, and make the API calls on the client side.
...
This was inspected with Chrome Dev tools and it should be noted that the JavaScript library and translation would be cached and respond quickly on repeated requests.
Event details
The event details contain an embedded map: https://ncras559.tc.gc.ca:4343/en/Event/Details/2019-08-00170The top loading contributors are:
...
We can see that, if nothing else, consistency has improved greatly. Average response times have dropped from over a second to around 500ms.
ArcGIS Enterprise Configuration
It would be worth evaluating the ArcGIS Server’s cache control, as mentioned here:
Publishing data
| Info |
|---|
These suggestions have been migrated to How to publish spatial data to eGIS |
Best practices for publishing and symbolizing data must be followed regardless of our hardware.
Create map caches where possible
Data that can’t be cached should be stored and displayed in the fewest and simplest features possible
Follow ESRI’s Performance tips for uncached maps
Re-project all data to WGS84 Web Mercator
Avoid all re-projection on the fly
Debate?
Test performance on all layers?
Web hooks, test new layers?
...