LLM with MCPs assessing application performance

Let me query Sentry for performance data on that URL.

Here's the performance data for Admin::CasePacketController#show.

Sentry parameterizes the transaction name, so I can't filter to packet 4621 specifically — the data below covers all case packet show pages.

Aggregate Performance

The massive gap between p50 (0.9s) and p95 (31.8s) indicates most requests are fast, but a long tail of extremely slow requests drags the average up to ~5s.

Top 10 Slowest Requests

The slow requests aren't new — they've been occurring since at least Sep 2025. However, the single worst request (84.7s) happened on Feb 11, 2026, and there's a cluster of slow ones in late Jan/early Feb 2026 (41s on Jan 22, 33s on Jan 24, 31s on Feb 15, 52s on Feb 15).

The likely cause: certain case packets have significantly more data (attachments, records, etc.) than others, causing some show pages to be dramatically slower. Packet 4621 may be one of these heavy records.

Let me check the development logs for Case Packet 4621.

Initial perf readout for /ops/case_packets/4621:

• Total ~6.8s; QueryLayer ~4.12s across 339 queries.
• Suspected main culprit: AuditTrail Entry/AxComment timeline queries; next step was to isolate the exact queries and call sites.

Latency Breakdown for Case Packet 4621

Total time: 6788ms QueryLayer time: 4115.7ms (339 queries, 53 cached) Templates time: 1749.3ms MemorySweep time: 1247.0ms

✅ Main Problem: "Case Packet Timeline" Audit Queries (~2.6s DB time)

These 3 queries are responsible for most of the slowdown:

1. Unscoped AuditTrail Entry query (293ms)

• Loads ALL removed AxComments for the entire system.
  • Query:

     SELECT "audit_entries".* 
     FROM "audit_entries" 
     WHERE "audit_entries"."entity_kind" = 'AxComment' 
       AND "audit_entries"."action_name" = 'remove'

2. Heavy AxComment Load via pk_id IN (...) (772ms)

• Loads a huge list of AxComment records based on IDs from the audit query.
  • Likely caused by the timeline rendering.

3. Serialized JSONB LIKE scan (1547ms+)

• This is likely the killer.
  • It searches audit_entries.delta_blob (JSON text) with a LIKE condition, which forces a full scan.
  • This is often seen when searching AuditTrail history by attributes in serialized text.

✅ Where It Happens

The log confirms it comes from:

Ops::CasePacketsController#archived_comments → app/controllers/ops/case_packets_controller.rb:742

This method is likely building the Case Packet Timeline UI section and triggering all these audit lookups.

Recommendation

This feature is extremely expensive and likely unused. Even if optimized, querying AuditTrail serialized JSON text like this will always be slow.

✅ Best options:

1. Remove the Case Packet Timeline feature entirely
2. Or replace it with a much simpler audit lookup (e.g. limit to last 24 entries and avoid JSONB LIKE)

The user wants me to check PostHog for click events on "Show Case Packet Timeline" in the opsnode project. Let me use the PostHog MCP tools to search for this.

Now let me search for click events on "Show Case Packet Timeline".

Here are the results for clicks on "Show Case Packet Timeline" in the opsnode project (last 30 days):

Only 2 clicks total in the last 30 days. Very low usage. Want me to expand the date range to see if there's more historical usage, or look at unique users who clicked it?

Night and day difference. Here's the before/after comparison for Admin::CasePacketController#show:

The performance improvement after Feb 18 is dramatic:

• Median response dropped from ~843ms to 118ms
• The extreme outliers are completely gone — worst case post-Feb 18 is just 1.8 seconds, vs 100+ second requests before
• p95 went from 31.9s to 613ms — the long tail was nearly eliminated

Whatever change went in around Feb 18 resolved the performance issue thoroughly. The page is now consistently fast with no significant outliers.