Reporting performance is generally understood to be the speed and efficiency with which reports are generated by the system when end-users perform a query. Performance depends on a variety of factors, including system bandwidth, number of concurrent users, volume of data to be presented, etc.
Naturally, some of these performance factors are “environmental,” that is, pretty much outside of the report developer’s control. Others, however, are not, and the smart report developer should be aware of these factors and use them to his advantage to create reports that perform efficiently and that don’t place undue burden on the system.
Let’s take a closer look at the two categories of factors affecting reporting performance–one environmental, one under your control as a developer.
Environmental reporting performance factors
These are the factors that are generally outside of the report developer’s control, and have more to do with the technical structure and architecture of the system on which BI runs.
- Hardware (CPU/RAM). The more robust a hardware solution, the better the overall report performance will be.
- Network bandwidth. Connectivity to the reporting server will play a large role in how responsive each report request will be.
- Operating system and database platform. The main factors are the overall file management performance and data load performance, and the connectivity to the database.
- Number of concurrent users. As with most web-based applications, user load shows a linear growth when it comes to response times.
- Data schema. Complexity of the database or data source schema will affect performance.
- Data Volume. Columns, rows and size/type of data value can burden your processor.
- Report definition complexity. The number of elements and attributes in a report will affect loading time, just like the more information a web page requests, the longer it will take to load.
Dashboards can make reporting lighter on the system while offering end-users great benefits.
Performance factors in the developer’s control
Now, here is the good news. Although the factors just mentioned are in general outside of the developer’s control, there are elements within a Web application model that depend (at least in part) on the developer, who can therefore affect reporting performance.
- Interactive paging. This allows the server to only load the proper amount of data and not become burdened, while letting the users view the information they request.
- Drill down, drill-through (on-demand data). Besides being beneficial to the end-user, these features make the report faster and more efficient, lightening the reporting load by given only the current state of requested data.
- Reusing elements. Reusing or sharing elements within a report allows for more complex reporting environments without adding burden to the server.
- Dashboard visualization. With a dashboard, the user gets only the information he needs, while the load on the system will be lighter. Also, dashboards present grouped data, aggregations, KPIs, etc., further compounding the technical benefits.
What these factors in the developer’s control have in common is that they create reports that limit the amount of data they present.