FineBI Performance Optimization

When you use FineBI, the following issues may arise and adversely affect its usage.

• The loading time is excessively long when you access dashboards.

• Frequent access to dashboards with large data volumes consumes excessive server memory, resulting in out-of-memory errors.

• Excessive concurrent access places excessive pressure on the server, resulting in server crashes.

• Request timeouts occur frequently.

• The system experiences long update durations, update errors, and update freezes.

If any of the above issues occur, performance optimization is required to improve the BI user experience.

Factors Affecting Performance

When performance issues arise in the system, you need to identify the root cause of the slowdown before analyzing potential improvements.

Server Performance

As a pure Java-based application, FineBI inherits the server resources when integrated into a server. Settings such as server virtual memory and connection pools often lead to numerous performance issues.

Data Preparation

• When you create self-service datasets, joins may produce a Cartesian product, which can cause data bloat, resulting in update failures or excessively long updates.

• The preview performance of SQL datasets affects update efficiency, which may result in slow data retrieval and preview or issues like stalled updates.

• Long text field values in the uploaded data can degrade performance and may even cause system crashes in severe cases.

Analysis Subject Creation

• When you create a dashboard, slow rendering speed will occur when there are excessive chart layers or groups, or if a single dashboard contains more than 30 components.

• When you deal with millions of data records, using nested DEF functions for multi-level calculations or the EARLIER function for calculation will result in significant performance degradation.

Server Performance Optimization

Data Preparation Optimization

Data Format

• You are not advised to upload data with field values exceeding 100 characters.

Data Processing

• You need to standardize data processing methods. N:N join operations need to be used sparingly, and precautions must be taken to prevent the generation of massive data volumes caused by N:N relationships.

Data Update

• You need to avoid numerous staggered, scheduled updates on single tables and prioritize global updates.

• Update tasks with identical schedules can be merged and executed concurrently, thereby reducing repeated updates of self-service datasets.

• You can regulate the update frequency and minimize update operations during the daytime when the system is active. Alternatively, you can configure resource pool parameters if such updates are unavoidable.

Data Usage

• Direct data connections require database performance checking to guarantee speedy data retrieval.

• For details, see Direct-Connected Data.

Dashboard Optimization

1. Data Type

For large datasets, you are advised to switch from direct-connection datasets to extracted datasets.

For slow database execution in direct connection scenarios, you can optimize SQL statements. Alternatively, you can refer to [Direct Connection] Transferring Parameters Through the Jump Function and reduce data volume based on this document.

2. Data Calculation

a. Check whether the dashboard involves heavy calculations, such as distinct counting, header filtering, and formula filtering. You can reduce calculation overhead, adopt alternative calculation methods, or move dashboard-level calculations to self-service datasets.

If large-data grouping for charts is required, you can perform the chart big data GNU Compiler Collection (GCC) update.

b. You need to minimize the use of the EARLIER function in DEF calculations. The upcoming WINDOW function in the BI system will fully substitute the EARLIER function in its applicable scenarios.

c. For datasets with millions of data records, you need to avoid deeply nested DEF functions to prevent performance degradation.

3. Component Quantity

Excluding filter components, you are advised to create no more than 30 components.

You are advised to add no more than 30 conditions for filter components. A single filter component can include multiple conditions.

For example, in the condition WHERE City = "Wuxi" OR (City = "Nanjing" AND City = "Suzhou"), although there may be only one filter component on the frontend, it corresponds to three filter conditions.