Functions vs Methods

Single line answer would be -

• Functions are set of instructions
• Methods are functions that are associated with objects

Let’s understand what they mean! For example, we have user objects in JSON with the following parameters -

{
  "id": "some-user-id",
  "email": "me@sabbir.dev",
  "is_verified": false
}

Now we have to determine if the user has verified his email or not by checking the value of is_verified . We can do this both via a function or a method . let’s code…

At line 32 we declared a function with an explicit parameter type User and returns bool type. The function is straight forward and will work with any struct that has a parameter named is_verified of type bool .

And at line 38 we declared a method that is associated with User type. It takes no parameter as it already have the object definition. And returns bool . In Go lingo we call it value receiver method, we also have a pointer receiver method to look at —

Pointer Receiver vs Value Receiver

TL;DR: 99% of the time in production we will be using a pointer receiver

So, we have a grasp on value receiver methods, let’s assume we are tasked to write a method that will verify user email and set is_verified to true

If we run the code the output should look like below —

Value Receiver Method:  false
Pointer Receiver Method:  true

Now, we have a value receiver function at line 33 and the output from value receiver function is not what we intended to be. Because every value receiver function copies the struct and creates a new instance of the struct for the functions use only. Any alteration of value is encapsulated within the function. So when we call u.is_verified after calling the value receiver function the value of the struct remains unchanged. Yes, we can return a value from the function and update it in the main function. But the code becomes too verbose and unmaintanable. Here comes pointer receiver methods to rescue, they take pointer of a struct and change the value globally, as it should be.

So, we should choose pointer receivers 1if we want to change the value of a struct within the method, and 2to avoid excessive memory usage by copy each time the method is called. Although for a struct small like ours, wouldn’t matter. For the sake of giving examples I have used both value receiverand pointer receiverfor the struct Userbut in real world, we should use either one of the methods, never both.

Please Note that, all struct fields, functions, and methods names are in lower case. This avoids external modules to import them, just like private functions in java, c++, c# etc.

Functions and Methods in Go was originally published in NewrozTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

At NewrozTech, we try to simulate the production environment by doing various tests with our service. One of the fundamental things is load testing primarily with Ddosify and finally with Jmeter. In this article, I will share my experience with a simple go tweak that made a huge difference.

Generally, we don’t use channels for sequential tasks like reading and writing a single row in the database. If we take an insert operation in the DB, our code will look more like the following,

which is completely fine and performed very well under 8K req/s load with our business logic. All the requests were processed within 5–15ms with our commodity hardware. But when we increased the load to 10K req/s, the service struggled to process all the requests. On average, 15% of our requests fail due to connection timeout issues.

Just by refactoring the above snippet to a buffered channel with capacity 1,

we were able to serve 9.3% more requests per sec. We have used 3 types of load available on Ddosify, linear, incremental, and waved . Though both of the methods delivered their lowest performance with waved load type, we observed overall improvement with the concurrent pattern.

The full diff between the two different methods is —

From the diff, we can also see that not only do we have fewer errors the server response time in total has also decreased except in waved load type. The Bad Requests are random and intentional to predict client-side issues. But we can also see the similarities in the 400 error count.

We started with 5K TPS, our target to achieve 10K TPS in our intranet. We were able to achieve the goal after a while here’s a demo —

I love how gracefully Go releases the resources and how little resources it consumes to serve thousands of concurrent requests. The final container size of the application was only 13mb, it took only <500mb memory to serve 10K requests, and it released all the resources almost instantly after the tests finished!

Happy hacking…

Tip for Go Services at Scale was originally published in NewrozTech on Medium, where people are continuing the conversation by highlighting and responding to this story.