A slow website needs a performance investigation, not just a bigger server

Adding CPU or memory may help a busy website, but it can also leave the underlying bottleneck untouched. Start by identifying which requests are slow, when the problem occurs and which resources are saturated.

Seven layers to examine

1. Application code: profile important requests and look for repeated queries, unnecessary work, memory use and blocking calls.
2. Web and application servers: review workers, connection handling, compression and caching against the workload.
3. Databases: inspect slow queries, execution plans, indexes and memory pressure. Test changes rather than adding indexes indiscriminately.
4. Operating system: investigate process limits, scheduling and network behavior. Change kernel parameters only when evidence supports it.
5. Storage: review latency, throughput, I/O wait and filesystem behavior.
6. Network and delivery: examine caching, payload sizes, connection setup and whether a CDN fits the content.
7. Ongoing monitoring: retain useful metrics and logs so the team can compare behavior before and after a change.

Make a controlled change

Record a baseline under representative load. Change one meaningful factor at a time, verify the effect and keep a way to return to the previous configuration. A synthetic benchmark is useful evidence, but it does not replace observation of the real user journey.

Agree which measures matter: response time distributions, throughput, error rates and resource use. A lower average response time can still hide a poor experience for the slowest requests.

UNIXDEV can help assess the application and infrastructure through managed operations and application maintenance. The scope and expected improvements depend on the findings.