Is microservices built with GoLang really fast?

Azizul Haque Ananto
4 min readMar 26, 2020
Courtesy: https://gfycat.com/blindfortunateibadanmalimbe

I’m pretty sure Go is one of the fastest languages to be considered. And writing Go codes are intuitive. The benchmark results all around the web really attract new developers to choose this as a professional language or some are trying to switch in this. But what are the caveats? Basically I like Go. Surely not for the hype, it’s really a very beautiful language to read, it’s clear and precise. One can easily understand what the code is trying to do. However, there’s a learning curve. And does it worth for a Java or Python or any other language president system to switch to Go just for the benchmarks?

Today I will try to find out some nitty cases that deflect our eyes in the flash of cool benchmark results. I will do some benchmarks in my mac (2.6 GHz 6-Core Intel Core i7, 16GB). Let’s start with a very basic one. The Hello World 😅 web app. (Every time I say this, I do laugh a lot 😂)

Very simple code. By the way, I won’t go through codes here. Just showing what I’m using to do benchmarks. Now let’s run our favorite wrk. (I used 200 connections on 20 threads for 20 seconds)

Hello World

Wow! That’s so impressive! 72k request per second! But in real-world, our applications are not Hello World 😂 They do reply something meaningful. In our case that can be a JWT token. Here’s the code —

Again simple. Just returns a JWT token on the same user a1b2c3. Atleast something meaningful, not the Hello World 😅 Let’s run wrk

JWT

Wait what! It’s better! 81k per second! Amazing! Definitely Go is fast. But here comes our typical scenario, we will mimic microservices where one service will call another. So we will make a service that will call our JWT app to make the token and it will print and return that. Assume that print is for logging, probably, we won't log token, but maybe some other things that are replaced by token now. The caller app is like that-

Nothing to explain here. Let’s run wrk -

service calls

Ok, it has dropped, hugely. 1.6k request per second. But to be honest, this is still a lot of requests/sec, not that impressive like the previous one. I am just trying to reflect, in real-world scenario these flashy benchmarks doesn’t solve a problem. There are trade-offs. One can obviously learn Go and implement it in their applications, but before that, they should try to simulate the whole thing locally at least, or do the cost analysis.

Why our code slowed down? There are two main reasons, the cost of HTTP connections (network overhead) and using the same machine to run both services. But in the cloud, that’s also a machine, even a single machine shares multiple virtual machines. This is just an example. In big systems, there can be hundreds of services talking to each other.

This is a very primitive idea of what can happen when network calls come in the spotlight. And also these examples are really basic with no validation and whatsoever. Also, there’s no serialization, no database calls or even no post calls, where performance can degrade more. And obviously ignore the code style (try to avoid that fatal 😐).

I do love learning new languages, so I would recommend anyone to learn Go. Even try to learn Rust, Elixir, these are really good for concurrency based app. But in real-life applications and production, there should be enough testing.

Lastly, Go is highly concurrent but this can be achieved with our favorite languages too. There are big companies using Go, Elixir, Rust to make high concurrency app. They have their computation power, we need to keep that in mind while designing our own app. Cheers! 🍺 Scold me in the comment section 😅

--

--

Azizul Haque Ananto

Software Engineer | Polyglot Programmer | Built systems for 100+ mil users