GOMAXPROCS, a good friend of DevOps
Since Go 1.5, the number of User-Level
threads that a Go App can run concurrently in each instance is determined by GOMAXPROCS. The value of GOMAXPROCS is defined as follows:
Since Go 1.5, the number of User-Level
threads that a Go App can run concurrently in each instance is determined by GOMAXPROCS. The value of GOMAXPROCS is defined as follows:
If you’ve written goroutines, you’ve probably come across sync.WaitGroup
for waiting on a group of goroutines. But in the sync
package, there’s another useful type I’d like to introduce: sync.Pool
, which helps reuse memory and reduce allocations for things that are used repeatedly.
When writing Go, a question that always comes up is whether to use a value or a pointer for a function. Let’s look at the difference.
When I was studying computer engineering, a question that always came up was why we needed to study subjects like Computer Architecture and Data Structures. It wasn’t until I graduated and started writing in Go that I realized why Go has data types with specific sizes, such as int8
, int16
, int32
, int64
, and others. Why not just have int
or number
like in lazy languages like TypeScript? It was only after reading about sizes in Go that I realized we can use our knowledge of Computer Architecture and Data Structures to help us write Go code that is as efficient as it should be.
In modern software development, focusing on getting things done quickly for initial use and then going back to clean up the details later (which is often never fully completed) usually results in difficulties when trying to add new features. This is because the code might be too tightly coupled, or if the demand for use increases, the system might not be able to scale as needed due to a lack of clear planning or structure in the software development process.
Today, we will introduce a set of guidelines for software development that helps create high-quality, easy-to-maintain, and scalable code. A popular and easy-to-understand set of guidelines is SOLID. In today’s examples, we will be using the Go language (because I’m comfortable with Go, haha).
Normally, when using a database for small-scale tasks in a container, we usually connect via TCP/IP, right? But did you know that you can easily improve performance by removing the TCP overhead by using Unix sockets instead? Let’s see what the results are.