Page Comparison

NEW FEATURES

Single Chart Word Export - Performance Improvement (BETA) 🗣️	pi#2438	29822 & 32731	Exporting - Word
We’re excited to offer a completely rebuilt Word (docx) export functionality which is almost instant and reflects any changes you make to charts on your screen (including legend selection). You can try it out by enabling the beta feature BROWSER_WORD_EXPORT (in pancredit_parameters table) and we’d love to hear your feedback and incorporate feedback into our upcoming releases. At present it only supports certain chart types (highcharts) which doesn’t include tables, card charts, maps. Any unsupported will simply fall back to the existing export functionality. Example of the section from the new Word output:

CHANGES

CHANGES

SCHEMA CHANGES

MINIMUM SERVER REQUIREMENTS

The following data was created by load testing a pi server running on AWS Fargate.  Load was created by automatically logging users in / out of the server.  Additionally manual testing was performed during the load to observe actual performance within the system.   

Explanation: 

 This testing was performed on the September 2024 Dashboard version.  We had noticed a degradation in performance in this version particularly in the June, May and August releases. 

This is not attributed to any one particular change, but rather is down to several different events / changes ; 

Updates to frameworks / libraries 

• Java 

• Tomcat 

Background

During our internal pre-release testing of this September 2024 dashboard release, we observed some notable performance degradation within the dashboard. This coupled with a handful of similiar issues reported in releases since our May 24 release, triggered a review of our minimum system requirements - to ensure these were set sufficiently, and to understand the cause.

Between the May 24 and August 24 releases, we have introduced several changes that have individually contributed to the overall degradation we observed, however no one specific change was the cause;

• Changes to frameworks / libraries 

  • Java

  • Tomcat

  • Grails

  • Angular 

• Removal of some server level caching

,

• - to make provision for horizontally scaling deployments 

• Redis for maintaining session across application nodes 

• Multi-lingual additions 

• New

category object

• Category Object (filter) features 

Organisations 

• Organisations

• Linked Data

connections 

• Connections 

• Custom

field logic 

 

For previous releases, the recommendation for the sizing of a single application node for nominal load was given as 1 vCPU and 2GB RAM 

We have tested additional combinations and our explanations, results and conclusions are below. 

There have also been two

• Fields logic 

• Two performance related code changes

made in the September release. 

• Better handling of encrypted variables 

• Application Optimisation to have also been introduced in this September 24 release

  • Improved handling of Encrypted Variables 

  • Application Optimisation - to reduce requests when refreshing the page 

  Analysis & Testing

The chart below logs the output produced by the dashboard (MIS_AUDITS) and shows the number of chart requests served by the dashboard per minute.  We use other metrics – but this served rate has proven to be highly correlated to performance and the user experience when interacting with the system.  The vast majority of requests are serving charts.  We tested the ability to perform configuration actions at the same time. 

Image Removed

The green the same time. 

Image Added

Note
Load Testing was performed on pi server running on AWS Fargate.  Load was created by automatically logging users in / out of the server, in addition to manual tests being conducted during the load, to observe actual performance. The repository we tested against included volumized users, categories, organisations and data connections. We also included (and used) Secured Variables too.

The Green band shows the high load areas we observe on customers dashboards that run on our Pi SaaS instances. 

The pink Pink line shows the point of instability we noticed on the during our internal pre-release September version, testing for the September 24 release - that caused nodes to become unstablebe impacted.  We were able to observe this consistently, and this was before the code fixes were applied and we made subsequent code changes to address the issues, and were based on a node with 1vCPU and 2GB RAM (these being our previous recommended settings for a single application node). 

 

We used a repository with volumised users, categories, organisations and data connections.  The repository also included (and used) secured variables. 

On these runs we altered the number of vCPU’s, RAM and maxThreads environment variable. 

Matrix 

 To observe the impact of changing resources, we performed multiple test runs, making amendments to

• vCPU’s

• RAM

• maxThreads (environment variable)

The table below details the finding we recorded for each run and configuration change.

Run	vCPU	RAM (GB)	Max Threads	Observed
1	2	4	20	System hit a limit at 170 charts served per minute.  The server remained stable at this point, and when load was reduced continued to operate efficiently.
2	2	4	30	The system performed well and was able to perform to ~350 chart requests. The server remained stable
3	2	4	40	The system performed well and was able to perform to ~400 chart requests. The server remained stable
4			50	The system was still able to perform to ~350 chart requests per minute, but the observed performance was significantly reduced.
5	1	4	40	The system was significantly slower even whilst no load was provided.  We struggled to load the system beyond ~120 charts per minute.  The server did remain stable.
6	2	8	40	The system was able to perform ~470 charts requests per minute, was stable and user experience was good even while loaded.  It was observed that the additional 4GB of RAM was not used by the system.
7	2	4	40	Following test 6, we re-performed test 5 to confirm that the additional 4GB of RAM was unnecessary, and the experience on this test 5 and 6 was comparable.
8	2 load balanced * 2vCPU	4GB	40	Where able to show that the resources where effectively run over load balanced nodes, and achieved ~1,000 charts per minute, and the solution was very stable even under this load.
9	As Above			Confirmed that the system could be loaded and unloaded without effect.

Results & Recommendations 

Our current recommendation is that a pi Node should be as follows. 

Minimum Requirements Based on our findings, we recommend that the following resource and configuration changes are applied to ensure optimal performance and stability of application nodes.

Resource Requirement

• 2vCPU 

• 4GB RAM 

Configuration Changes

Recommended Settings

We recommend - the following configuration change.

Tomcat MaxThreads should be set to the same value as the repository MaxConnections (our recommended value is 40)

• PI_TOMCAT_MAX_THREADS = 40

• PI_TOMCAT_MAX_CONNECTIONS = 40

Also, with the increase in memory to 4GB RAM, you should make sure 3GB is allocated to tomcatthe Tomcat, leaving 1GB for the operating system.

• PI_TOMCAT_MAX_MEMORY = 3072