Performance Engineering

Fix a Slow Web Application

Find the bottleneck before rewriting the system. SazM profiles the request path, database, integrations, and delivery layer, then applies focused performance fixes that can be measured.

Describe the performance problem

Slow is a symptom, not a diagnosis

A slow page can be caused by an unindexed query, an overloaded connection pool, a synchronous third-party request, oversized assets, origin distance, or too much work inside one request. Optimizing the wrong layer makes the code more complicated without making the product meaningfully faster.

The first step is therefore measurement: identify where time is actually being spent and which bottleneck has the highest business impact.

Focused performance projects

  • Slow PostgreSQL or MySQL queries and missing indexes
  • Database lock contention and connection-pool exhaustion
  • Slow API endpoints and long-running request handlers
  • Synchronous third-party APIs starving application workers
  • Large-file and media delivery overwhelming an origin server
  • CDN, caching, and edge-delivery bottlenecks
  • High-latency pages on mobile or for geographically distant users
  • Small performance regressions that need a targeted production fix

Evidence from production work

On one legacy PHP modernization, decoupling the frontend and moving delivery toward the edge reduced page-load latency from 1.8 seconds to 680ms. On another platform, decoupling large document assets to object storage with CDN caching reduced server memory usage by 75%. High-write workloads have also been improved by moving third-party ingestion behind queues and adding indexes around time-series access patterns.

These are examples of different bottlenecks requiring different fixes — not a promise that every application will produce the same result.

What the engagement produces

  • A measured baseline of the slow path
  • Identification of the highest-value bottleneck
  • Focused code, query, caching, or infrastructure changes
  • Targeted regression verification for the affected path
  • Before-and-after measurements where the system exposes a reliable metric

Start with the slow thing

Send the URL or endpoint, what feels slow, when it became slow, approximate traffic or dataset size if known, and any profiling or monitoring data you already have.

Describe the bottleneck