Your application is slow and users complain? Read this before you buy a bigger server
Users say the application is slow and the proposed fix is a bigger server? Usually wrong. Where the time goes, how to measure it, and when a server helps.
Vlado Pandžić · Founder · Senior .NET architect
Published · 4 min read
Users complain. Screens spin, a report takes two minutes, and on Monday morning nothing works the way it should. Someone suggests a bigger server or a larger cloud plan. You buy it, things get a little better for two months, and then it’s back to the same. Only now the bill is bigger, every month.
That happens because in most cases a bigger server is the answer to the wrong question.
Why a bigger server rarely fixes it
Picture a warehouse worker who walks to the shelves and back separately for every item on an order. For an order of 400 items, that is 400 trips. You can buy them a faster forklift and they will get a little quicker, but the real fix is to pick everything in one trip.
Business applications very often do exactly that. The most common causes of slowness are not in the server’s power, but in the way the application works:
- Hundreds of queries for one screen. The application asks the database for every row separately, instead of once for all of them.
- A database without the right indexes. To find one record, the database reads the whole table. While the table is small, nobody notices. After five years of data, everybody does.
- Reports that load everything. The application pulls all the data into memory and only then filters and adds it up, instead of letting the database do it.
- Calls to external services one after another. Each call waits for the previous one, so the seconds add up.
- Nothing is remembered. Data that changes once a day is calculated from scratch every time a screen opens.
A bigger server makes each of these a little faster, and every month there is more data. That is why the problem always comes back.
The symptoms tell you where to look
You don’t have to be a developer to narrow it down. This is what a manager can notice on their own:
| What you notice | Where the problem usually is |
|---|---|
| Only some screens or reports are slow | In the code or the queries behind those screens |
| Everything gets slower as data grows | In the database: indexes and the way data is fetched |
| It is slow at certain times of day | Something else runs at the same time: nightly jobs, backups, data imports |
| It has been slow since the new version | A change in that version, and that one is found fastest |
| Everything is slow, all the time, for everyone | Only now is it time to look at the server and the network |
How slowness gets fixed: by measuring, not guessing
The most expensive mistake is fixing what someone thinks the problem is. The right order is always the same:
- MeasureWhere exactly the time goes
- CauseThe three biggest culprits
- FixWhat hurts most goes first
- VerifyNumbers before and after
- Measure. Tools that already exist for .NET applications and SQL Server show exactly which screen is slow, how many queries it sends to the database and how long each one takes. After that, there is no guessing.
- Cause. It usually turns out that two or three things cause most of the problem. They get fixed first.
- Fix. Start with what users feel most: a screen everybody opens every day matters more than a report run once a month.
- Verify. The same measurement before and after. Not “it feels faster”, but “this screen used to open in 8 seconds and now opens in one”.
Fixes like these are often a matter of days or weeks, not months, and they don’t require rewriting the application. Once done, they aren’t billed every month like a bigger server.
When you do need a bigger server
Sometimes you do. If the measurements show that the application is written sensibly and the server is constantly at its limit because there are more and more users and more work, then a bigger server is the right decision. The difference is that you make that decision based on numbers, not because it is the quickest thing to say.
How we work
ProCoding is a .NET studio from Split, Croatia. Performance is one of the things we do most often: in .NET applications, ASP.NET Core, Blazor, Entity Framework, SQL Server and Azure.
We start by measuring your application, and you get a list of causes ranked by how much they hurt. Then we fix them, or your team does, whichever suits you better. The first step is a free 30-minute call in which we go through the symptoms and see where we would measure first.