In this guide 6 sections
Measure first. If CPU, memory or disk sit near their limit while queries are already efficient, hardware is the constraint and a bigger server helps. If resources idle while one query or page crawls, the code is the constraint. Test a larger instance on a copy before you buy it.
Ask what is slow before asking what to buy
A quote for bigger hosting usually arrives right after a complaint, with no measurement behind it. Slowness has several causes. An overloaded server is one. A missing database index, a chatty page and a slow third-party call are others.
Ask for the baseline first. Which screens are slow, for which users, at what hour? A month-end stock report that crawls points to different work than a login that crawls all day, so write both down.
What it looks like when hardware is the limit
Look at the server during the slow period. When hardware is the limit, the graphs say so plainly. The numbers stay high across every page, not just one.
Queries finish quickly when run alone, yet everything queues once many users arrive. Adding vCPUs or RAM helps here, because the work itself is reasonable and simply has too little room.
- CPU pinned high across all cores for long stretches
- Memory full, with the operating system swapping to disk
- Disk wait (iowait) rising while the database writes
- Connection pool exhausted, requests waiting in line
What it looks like when the code is the limit
The opposite picture is a server that is mostly idle while one screen takes many seconds. Resources are free. The time goes elsewhere: a query scanning a whole table, a loop that calls the database once per row, or an API call waiting on a partner.
Open the slow query log or the database’s execution plan for the worst page. A sequential scan on a large table, a missing index or an N+1 pattern is a fix measured in hours. It costs less than a monthly hosting bill.
- Low CPU but high response time on a single page
- One query dominating the slow query log
- Many identical queries fired for one page load
- Long waits on an outside payment or courier API
Test a bigger instance on a copy first
Do not pay for an upgrade on faith. Clone production into staging, resize the clone for a day or a week, and rerun the same scripted journeys you used for the baseline. Cloud providers bill by the hour, so the trial is cheap.
Compare the median and the slow tail before and after. If the slow page barely moves, the hardware was never the problem. You have saved the contract. If everything improves, buy it with evidence in hand.
Fix in the right order
The sensible order is cheap code and database fixes first, then right-sizing, then a larger plan only if the graphs still show a ceiling. Re-measure each step against the baseline.
Keep the trial results in a note beside the quote. When the hosting rep pushes for a bigger plan, answer with timings.
Your next step: ask whoever quoted you to send the CPU, memory and slowest query figures from the last slow day.
Server or code decision sheet
Two columns on a single worksheet, hardware signs and code signs. Rows cover CPU, memory, disk wait, connection pool, slowest query, queries per page and external call time. Each row has a reading from the slow period and a tick for which column it supports, ending in a recommended first action.
Open a blank worksheet to printQuestions owners ask
Will a bigger server ever hide a code problem?
Yes, for a while. Extra capacity masks an inefficient query until data or traffic grows into it, and then the same slowness returns with a larger bill.
How long should the larger instance trial run?
Long enough to cover a busy period and the heaviest report. A day is often enough for a web page, while month-end jobs may need a week.
Who can read these graphs for me?
Your hosting dashboard shows CPU, memory and disk. A developer or performance engineer reads the database logs and execution plans and explains them in plain terms.
Is moving to the cloud a performance fix?
Not by itself. A slow query is equally slow on any hardware, so measure before and after a move just as you would for an upgrade.