Skip to content
Notifications
Clear all

Help: Reporting module in our current platform is painfully slow.

1 Posts
1 Users
0 Reactions
0 Views
(@chrisk)
Estimable Member
Joined: 3 weeks ago
Posts: 152
Topic starter   [#23389]

We’ve been experiencing unacceptable latency in our support platform’s reporting module, and after a week of analysis, I’ve concluded the problem is architectural, not simply a matter of query optimization. The platform in question is a major SaaS provider (I'll refrain from naming it publicly for now, but can share via DM). When generating a report spanning a 30-day period for a mid-sized team (85 agents), the system takes upwards of 4 minutes to render a simple summary of ticket volume, resolution time, and agent performance. This is blocking our daily standups and makes ad-hoc trend analysis impractical.

I’ve performed some basic diagnostics with the browser’s developer tools and can confirm the delay is server-side. The network tab shows a single POST request to `/api/v1/analytics/run_report` that remains in a “pending” state for the majority of the load time. Upon completion, the response payload is a relatively modest 120KB of JSON. This suggests the bottleneck is in data aggregation and retrieval, not data transfer.

My hypothesis is that the platform is performing full-table scans on its fact tables for each report request, likely due to a lack of proper indexing or materialized views for common reporting dimensions. To test this, I attempted to run the same report for a 1-day window, a 7-day window, and the 30-day window. The response times scaled near-linearly with the date range, which is a strong indicator of the absence of pre-aggregated data.

```
Time Range | Approx. Response Time
-----------|----------------------
1 day | 8 seconds
7 days | 55 seconds
30 days | 243 seconds
```

Given my expertise in backend systems, I’m looking for a platform comparison from a performance engineering perspective. Specifically:

* **Database Architecture:** For platforms you’ve evaluated or use, what is their underlying approach to reporting? Do they leverage a separate, OLAP-optimized data warehouse (e.g., Redshift, BigQuery), or do they query the operational OLTP database directly?
* **Caching Strategy:** Is there evidence of intelligent cache layers for report data? Are results of common queries materialized on a scheduled basis?
* **API Responsiveness:** Have you conducted load tests on the reporting APIs? What were the p95/p99 response times for complex reports under concurrent user load?
* **Export Performance:** Is the performance degradation even more severe when exporting large CSV datasets, indicating perhaps different query paths?

We are at the point where this performance deficit is a critical business pain. I’m compiling a list of alternative platforms to propose, but need data-driven insights beyond marketing claims. Any detailed observations, especially those that include methodology for measuring report performance, would be invaluable.

-ck



   
Quote