I've been conducting a detailed performance and cost analysis of our LogRhythm deployment since the 7.7 update was applied last week, and the results are concerning. The primary issue manifests as a significant degradation in console responsiveness, specifically within the Investigate and Analytics modules. Page load times have increased by an average of 300-400%, and complex query execution now frequently times out where it previously completed in under 10 seconds. This isn't a subjective feeling; it's based on systematic timing data collected from our user sessions and application performance monitoring.
Our environment is a standardized, well-provisioned AWS deployment where we meticulously track instance performance against cost. The console components run on a dedicated `c5.4xlarge` instance group, and the database is on RDS using `db.m5.2xlarge`. Prior to 7.7, CPU utilization on the console instances averaged 35-45% during peak business hours. Post-update, we are consistently seeing sustained periods at 85-95% utilization, with corresponding spikes in read latency on the RDS instance. This suggests a fundamental change in query efficiency or data handling.
I have ruled out the usual infrastructure culprits through the following checks:
* Baseline network throughput and latency between components remains unchanged.
* No new data volume spikes correlate with the update timeline; our daily ingest is within 2% of the 30-day rolling average.
* AWS Cost Explorer shows no anomalous scaling events, confirming the performance drop is not due to a reduction in resources but an increase in demand per operation.
The specific performance regression appears to be tied to dashboard rendering and any search operation that involves multiple data correlations. A simple timeline query in Investigate that previously took 1.2 seconds now takes 4.7 seconds. More critically, from a FinOps perspective, this degraded performance has a direct cost implication. The sustained high CPU utilization negates the effective discount of our Reserved Instance commitments for these compute families, as we are now operating at a consistent "peak" load, reducing the cost-optimized buffer we engineered.
Has anyone else performed a quantitative performance comparison pre- and post-7.7? I am particularly interested in:
* Measured changes in console response times for standard operations.
* Any observed changes in backend database load (queries per second, read IOPS).
* Whether deploying additional console instances as a horizontal scaling measure has provided a linear improvement or if the bottleneck appears to be elsewhere, such as the database or platform services layer.
I am compiling metrics to present to our account team, but community data would help establish whether this is an isolated configuration issue or a broader pattern requiring a platform hotfix.
Spreadsheets or it didn't happen.