HENGSHI SENSE Product Performance Issues Guide

Dataset Operation Guide

1. Avoid creating new aggregated fields that are not intended for analysis on datasets of the types "Multi-Table Union," "Data Aggregation," and "Data Merging." This is because these three types of datasets perform real-time union, aggregation, and merging calculations during queries. Creating new aggregated fields (such as sum, avg, etc.) on the final dataset will exponentially increase the cost of the dataset. (For example, A join B -> C, adding three aggregated fields on C, the complexity of C during queries will be 3 (the multiple introduced by the three aggregated fields) + 1 (the original join of A and B) = 4 times the join cost). Consider adding aggregated functions in the calculation metrics of the Chart.
2. Avoid nesting multiple layers of datasets of the types "Multi-Table Union," "Data Aggregation," and "Data Merging." This is because these three types of datasets perform real-time union, aggregation, and merging calculations during queries. The more layers constructed, the greater the cost generated, and the slower the analysis. If the generation process cannot be simplified, consider: 1.) Enabling the "Acceleration Engine" on the final dataset, which will solidify the results of the dataset generation, so that the next query will not generate the dataset in real-time. (Note: After enabling the acceleration engine, the basic permissions of the dataset are the owner's permissions, and all subsequent permission settings are based on this foundation.) 2.) Implementing the complex generation process in the source database to generate a table within the customer's business database, and then creating a dataset on this result table.

Dashboard Operation Guide

1. It is recommended that a single Dashboard contain no more than 20 Charts. Too many Charts will increase the pressure on backend data source queries and frontend page rendering.
2. During the editing of a Chart, fields with fewer distinct values should be selected for dimensions, comparison dimensions (tables), etc.; otherwise, it will lead to poor visualization effects and exacerbate performance issues.
   1. The term "distinct value" refers to the number of unique values for this field in the data source.
3. Clicking the refresh button on the Dashboard and Chart pages will bypass any existing cache, re-pushing the query to the data source (whether it is imported into the engine or not) to retrieve the result data, which will then be rendered and displayed on the page.

System Settings Performance Related

1. In the system settings, there is a "Chart Data Cache Period." Within this period, repeated queries, except for the first one, will use the cache and will not be pushed down to the data source, thus not consuming system resources. Users can consider adjusting this setting based on their business scenarios. For example, if the analysis is in a T+1 mode, they can set this value to 86400, so that repeated queries within a day will not consume system resources.

Note:

1. Performance scales linearly with concurrency, which is closely related to the number of simultaneous queries, the number of concurrent users, the number of simultaneously opened Dashboard pages, and the number of Charts on the Dashboard pages.

Browser Page Load Performance

Mainly enable https 2.0 on the reverse proxy side and enable gzip compression, refer to Reverse Proxy Considerations