[oyi77]

Closes #1037

Problem

The analytics dashboard becomes progressively slower as usage history grows, with 3 root causes:

1. Full table scan — getUsageDb() fetches every row in usage_history with no date filter
2. N+1 sequential cost lookups — calculateCost() is awaited one-by-one inside a for loop
3. 6 separate COUNT queries — /api/v1/search/analytics fires 6 round-trips for data that fits in one query

Changes

File	What changed
src/lib/usage/usageHistory.ts	getUsageDb(sinceIso?) — optional date param pushes filter to SQL
src/app/api/usage/analytics/route.ts	Pass 365daysAgo as sinceIso (heatmap never needs more)
src/lib/usageAnalytics.ts	Replace sequential await calculateCost() with Promise.all()
src/app/api/v1/search/analytics/route.ts	Merge 5 scalar COUNT/AVG queries into one CASE WHEN aggregate

Expected improvement

Entries	Before	After (est.)
~500	< 1 s	< 1 s
~5 000	3–8 s	< 1 s
~50 000	30 s+	1–2 s

Test plan

• All 1439 unit tests pass locally
• getUsageDb backward-compatible (callers without sinceIso get old behavior)
• Search analytics response shape unchanged
• Manual: load /dashboard/analytics with large dataset and confirm faster response

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request optimizes analytics performance by capping history lookups to 365 days, consolidating multiple SQL queries into a single aggregated call, and parallelizing cost calculations. Review feedback suggests further refining the cost calculation logic to handle large datasets more efficiently by implementing caching for redundant lookups and batching promises to prevent memory pressure. Additionally, using COALESCE in the aggregated SQL query was recommended to improve null handling directly within the database layer.

[gemini-code-assist]

While Promise.all is an improvement over sequential await, calling calculateCost for every entry (up to 50,000 as per the PR description) is still highly inefficient. Each call to calculateCost performs a dynamic import() and a database lookup for pricing data. Since most entries share the same provider and model, you are performing thousands of redundant database queries.

Consider fetching all unique pricing records once at the start of computeAnalytics and then calculating costs synchronously in the loop. If refactoring calculateCost is not feasible, at least implement a local cache for the pricing lookups to avoid redundant I/O.

[gemini-code-assist]

Executing Promise.all on an array of 50,000 promises can lead to significant memory pressure and may impact the responsiveness of the event loop. For very large datasets, it is generally safer to process the array in smaller batches or use a concurrency-limited promise pool.

[gemini-code-assist]

The use of SUM(CASE ... END) and AVG(CASE ... END) is a great way to merge multiple queries. However, note that if no rows match the WHERE clause, these aggregates will return NULL in SQLite. While your current code handles this with the null-coalescing operator (?? 0) on lines 44-48, using COALESCE(SUM(...), 0) directly in the SQL would be slightly cleaner and more robust.

      .prepare(
        `SELECT
          COUNT(*) as total,
          COALESCE(SUM(CASE WHEN timestamp >= ? THEN 1 ELSE 0 END), 0) as today,
          COALESCE(SUM(CASE WHEN status >= 400 OR error IS NOT NULL THEN 1 ELSE 0 END), 0) as errors,
          AVG(CASE WHEN duration > 0 THEN duration END) as avg_duration,
          COALESCE(SUM(CASE WHEN duration > 0 AND duration < 5 THEN 1 ELSE 0 END), 0) as cached
         FROM call_logs
         WHERE request_type = 'search'`
      )

[diegosouzapw]

Thanks @oyi77 for the analytics performance optimization! The parallel cost calculation and merged queries will make a huge difference for users with large datasets. Merged into v3.5.4.