fast

Written by Martín E. Zahnd

Published: 2023-10-10 22:57

Tags: programming, architecture


If your service is slow, you’re in trouble.

Slow

I’ve been working on a project with a slow backed, a really slow one. Sometimes it took 30 seconds to retrieve data 1, which represents 3 timeouts for the server. So, in practice, it took more than 30 seconds to some things, or worse: asking the user to “push the button” four times. Oh, and, when I started working on this project, the app didn’t handle timeouts, which is also very important. It does now, fortunately.

This is my “first hand experience” from a technical perspective in this matter.

Is this important at all?

Technically, no that much. Just click it again and it works. But systems exist provide value to other people, call it entertainment or helping them achieve something easily, but the mean is the same: do something for someone. As such, they are always in contact with us (humans) and we don’t really like waiting 30 seconds. Not in anything tech related, at least. This leads to angry clients, that is, people who don’t like waiting or clicking it again 2, and angry clients lead to less revenue.

That’s no secret, but I’ve seen a few small projects and big corps too not caring at all about this.

What should we do then?

First of all, handle timeouts.

They do exist, and they are not always your servers fault: maybe the user went inside an underground parking and lost signal, maybe he or she is in a rural area without proper internet access, who knows! But we know that “client code” is always harder to deploy and debug than “server code”, especially in mobile devices, because they depend on the user (or the operating system, for that matter) updating your app.

Second, take your time to analyze each request in your server and try to detect your services bottlenecks.

And finally, invest in a better server or cloud infrastructure if needed. For example, if your requests “were fine” but your startup just got a lot of attention and suddenly you’re serving request to 10x more clients, don’t try to limit your number of instances just to save some money. Better keep your old and new clients happy (by serving them fasts requests) and start working on reducing your system’s bottlenecks as much as possible in the meantime.

  1. The same data was retrieved in 1 to 3 seconds when cached, and that’s still painfully slow for a 100 KiB JSON. 

  2. I’ve notice that many users show resistance to clicking again a button. The expect it to work and show a message saying “Yeap. It worked.”.