Forem: CodePiper

Mastering the Concurrency In Go Playlist | Blogs + Youtube Videos

CodePiper — Wed, 16 Aug 2023 15:59:55 +0000

Hey
Just writing this blog for the update of "Mastering the concurrency in Go" Series. We have published:

Full YouTube Playlist: https://www.youtube.com/playlist?list=PLPCpN15kbMlSyd6pR9qgwp7XUcu_3sgqk

S1E1: Concurrency In Go | Goroutine | Channels | Waitgroup | Buffered Channel | by Arshlan | Jul, 2023 | Medium
S1E2: Concurrency Boring Desing Pattern in Go | by Arshlan | Jul, 2023 | Medium
S1E3: Mastering Concurrency with Worker Pool in GoLang: A Scalable Solution for Efficient Task Processing | by Arshlan | Aug, 2023 | Medium
S1E4: Mastering Concurrency Fan-In Design Pattern | by Arshlan | Aug, 2023 | Medium
S1E5: Mastering the Concurrency in Go with Fan Out Design Pattern | by Arshlan | Aug, 2023 | Medium

S1E3: Mastering Concurrency with Worker Pool in GoLang: A Scalable Solution for Efficient Task Processing

CodePiper — Thu, 03 Aug 2023 17:12:25 +0000

Today we will continue our Concurrency Design Pattern web series, in this blog we will learn about the Boring Design Pattern. If you want to keep update with the latest video, then please subscribe my YouTube channel.
For full explanation: https://youtu.be/7IDKae4SvDw
Full Playlist: https://www.youtube.com/playlist?list=PLPCpN15kbMlSyd6pR9qgwp7XUcu_3sgqk

Concurrency is an integral aspect of modern software development, enabling applications to perform multiple tasks simultaneously and efficiently utilize system resources. In the world of GoLang (Golang), concurrency is a powerful feature that can significantly enhance the performance of applications, especially in scenarios with numerous computational or I/O-bound tasks.

We'll explore the essential concept of the Worker Pool pattern, a concurrency design pattern that optimizes task processing in GoLang. We'll dive into what a Worker Pool is, why it's indispensable in concurrent programming, and how you can leverage its benefits to create efficient, scalable applications.

What is a Worker Pool?
The Worker Pool pattern is a concurrency design pattern used to manage a group of worker goroutines that process incoming tasks concurrently. It involves creating a pool of goroutines (workers) to process tasks from a shared queue (job queue) efficiently. By limiting the number of concurrently running goroutines, the Worker Pool pattern helps prevent resource contention and overloading the system, leading to improved performance and stability.

Use Cases for Worker Pool:

Web Servers and Network Applications: Worker Pools are ideal for handling incoming client requests concurrently. Each incoming request can be treated as a task, and worker goroutines process these tasks in parallel, ensuring fast and responsive server performance.

Data Processing and Batch Jobs: When dealing with large datasets or performing computationally intensive operations, a Worker Pool can divide the workload into smaller tasks. The worker goroutines process these tasks in parallel, significantly reducing the overall processing time.

Resource Management: In scenarios where resource-intensive operations, such as database connections or file I/O, need to be managed efficiently, a Worker Pool can be employed. A pool of pre-initialized resources is maintained, and worker goroutines use these resources as needed, avoiding the overhead of creating and destroying resources for each task.

Why Do We Need Worker Pools?

Optimal Resource Utilization: Worker Pools help maintain a balance between the number of concurrent tasks and available system resources. By limiting the number of workers, we ensure efficient resource utilization and prevent resource exhaustion.

Improved Responsiveness: For applications handling multiple concurrent tasks, using a Worker Pool ensures that tasks are processed promptly, leading to improved responsiveness and reduced waiting times.

Controlled Concurrency: A Worker Pool provides a straightforward mechanism to control the degree of concurrency in the application. By adjusting the number of workers in the pool, we can fine-tune the application's performance to match the available resources.

Stability and Scalability: Worker Pools play a crucial role in creating stable and scalable applications. They prevent potential bottlenecks and help the application gracefully handle varying workloads.

Youtube Channel: https://www.youtube.com/@codepiper
Github Link: CodePiper/GO/concurrency-patterns/Basics at main · arshad404/CodePiper (github.com)
Linkedin: www.linkedin.com/in/arshad404

S1E2: Concurrency Design Patterns: Boring Desing Pattern in Go

CodePiper — Sat, 29 Jul 2023 10:58:33 +0000

Today we will continue our Concurrency Design Pattern web series, in this blog we will learn about the Boring Design Pattern. If you want to keep update with the latest video, then please subscribe my YouTube channel (It motivate me to make more such videos for the community).
Channel Link: https://www.youtube.com/@codepiper
Boring pattern Video Link: https://www.youtube.com/watch?v=RidHWJCveLw

Let's first see where we can apply this pattern and what can be the use cases of this pattern:

Small and Independent Tasks: The boring design pattern is well-suited for scenarios where you have several small and independent tasks that can be executed concurrently. Each task can be encapsulated within a separate goroutine.
I/O-Bound Operations: For applications that involve I/O-bound operations (e.g., reading and writing to files, making network requests), the boring design pattern can be beneficial. Concurrently executing I/O-bound tasks using goroutines and channels can improve overall throughput and performance.
Event Handling: When dealing with events or event-driven programming, the boring design pattern can be employed to handle multiple events concurrently. Each event handler can run in its own goroutine, responding to events as they occur.

Now we will see how can we implement this pattern with the help of goroutine and waitgroups

package main

import (
    "fmt"
    "sync"
)

// Boring function that returns a channel to send boring messages
func boring(msg string) <-chan string {
    ch := make(chan string)
    go func() {
        defer close(ch) // Close the channel when the goroutine exits
        for i := 1; i <= 5; i++ {
            ch <- fmt.Sprintf("%s: %d", msg, i)
        }
    }()
    return ch
}

func main() {
    aliceCh := boring("Alice")
    bobCh := boring("Bob")

    // Receive messages concurrently
    var wg sync.WaitGroup
    wg.Add(2)

    go func() {
        for msg := range aliceCh {
            fmt.Println(msg)
        }
        wg.Done()
    }()

    go func() {
        for msg := range bobCh {
            fmt.Println(msg)
        }
        wg.Done()
    }()

    wg.Wait()
}

Github Link for the same code: https://github.com/arshad404/CodePiper/tree/main/GO/concurrency-patterns/Boring

S1E1: Concurrency In Go | Goroutine | Channels | Waitgroup

CodePiper — Sun, 23 Jul 2023 11:45:32 +0000

I am happy to announce that I have started a new series on Concurrency Design patterns with the working code. This playlist will contain 9-10 coding + concept videos. For full detail explanation please go to the CodePiper Youtube channel video: https://youtu.be/eTJ7P0RCZJc

This blog will cover

Goroutines
Waitgroup
Channel
Buffered Channel
Deadlock in concurrency

Goroutine:
Goroutines are the building blocks of concurrent programming in Go (often referred to as Golang). They are lightweight, independently executing functions that run concurrently with other goroutines in the same address space. Goroutines are managed by the Go runtime, and they utilize the available CPU cores efficiently through a technique called "multiplexing." You can think of a goroutine as a function that runs independently and concurrently with other functions, allowing for efficient and scalable concurrency in Go programs.

func printNumbers() {
    for i := 1; i <= 5; i++ {
        fmt.Printf("%d ", i)
        time.Sleep(100 * time.Millisecond)
    }
}

func printLetters() {
    for ch := 'a'; ch <= 'e'; ch++ {
        fmt.Printf("%c ", ch)
        time.Sleep(100 * time.Millisecond)
    }
}

func main() {
    go printNumbers() // Start a new Goroutine for printNumbers()
    printLetters()    // Execute printLetters() concurrently with the Goroutine
}

WaitGroup:
WaitGroup is a synchronization primitive provided by the Go standard library in the sync package. It is used to wait for a collection of goroutines to complete their execution before proceeding further in the main goroutine. A WaitGroup is essentially a counter that is incremented when a new goroutine is started and decremented when a goroutine finishes its task. The main goroutine can call Wait on the WaitGroup, which will block until the counter becomes zero (i.e., all goroutines have completed their tasks and called Done on the WaitGroup). It helps in coordinating the termination of multiple goroutines.

func printNumbers(wg *sync.WaitGroup) {
    defer wg.Done() // Notify WaitGroup that this Goroutine is done when the function returns
    for i := 1; i <= 5; i++ {
        fmt.Printf("%d ", i)
        time.Sleep(100 * time.Millisecond)
    }
}

func printLetters(wg *sync.WaitGroup) {
    defer wg.Done() // Notify WaitGroup that this Goroutine is done when the function returns
    for ch := 'a'; ch <= 'e'; ch++ {
        fmt.Printf("%c ", ch)
        time.Sleep(100 * time.Millisecond)
    }
}

func main() {
    var wg sync.WaitGroup
    wg.Add(2) // Add the number of Goroutines to wait for

    go printNumbers(&wg) // Start a new Goroutine for printNumbers()
    go printLetters(&wg) // Start a new Goroutine for printLetters()

    wg.Wait() // Wait until all Goroutines in the WaitGroup finish
    fmt.Print("Okay you can go")
}

Channel:
A channel in Go is a typed conduit that allows communication and synchronization between different goroutines. It is a way for goroutines to send and receive values to and from each other. Channels provide a safe way to exchange data and communicate between goroutines, preventing race conditions and other concurrency-related issues. Channels can be used to pass data from one goroutine to another, enabling the coordination of concurrent tasks effectively. Channels can be unbuffered or buffered, depending on their capacity.

func sender(ch chan<- int) {
    for i := 1; i <= 10; i++ {
        ch <- i // Send data to the channel
    }
    close(ch) // Close the channel after sending all data
}

func receiver(ch <-chan int) {
    for num := range ch {
        fmt.Printf("%d ", num) // Receive data from the channel
    }
}

func main() {
    ch := make(chan int)

    go sender(ch) // Start a new Goroutine for the sender
    receiver(ch)  // Execute the receiver concurrently with the Goroutine
}

Buffered Channel:
A buffered channel is a type of channel in Go that has a fixed capacity to hold a certain number of elements. When you create a buffered channel, you specify the capacity as the second argument to the make function. For example, ch := make(chan int, 10). In this case, the channel ch can hold up to 10 elements. When a goroutine sends a value to a buffered channel, it will be added to the channel's internal buffer if there is space available. If the channel is full, the sending goroutine will block until there is room in the buffer. Similarly, when a goroutine tries to receive a value from a buffered channel, it will receive data from the buffer if it's not empty. If the buffer is empty, the receiving goroutine will block until data is available.

func main() {
    ch := make(chan int, 3) // Create a buffered channel with a capacity of 3

    ch <- 1 // Send data to the channel
    ch <- 2 // Send more data
    ch <- 3 // Send even more data

    // ch <- 4 // Sending a 4th value would cause a deadlock because the channel is full

    fmt.Println(<-ch) // Receive data from the channel
    fmt.Println(<-ch) // Receive more data
    fmt.Println(<-ch) // Receive even more data

    // fmt.Println(<-ch) // Receiving a 4th value would cause a deadlock because the channel is empty
}

NOTE: Using buffered channels can sometimes improve the performance of concurrent programs by reducing contention between goroutines, as long as the buffer size is chosen wisely based on the specific use case. However, it's essential to be mindful of buffer sizes to avoid consuming excessive memory.

func producer(ch chan<- int) {
    for i := 1; i <= 5; i++ {
        fmt.Printf("Producing %d\n", i)
        ch <- i
        time.Sleep(500 * time.Millisecond) // Simulate some work by the producer
    }
    close(ch)
}

func consumer(ch <-chan int) {
    for num := range ch {
        fmt.Printf("Consuming %d\n", num)
        time.Sleep(1 * time.Second) // Simulate some work by the consumer
    }
}

func main() {
    normalCh := make(chan int)      // Normal channel
    bufferedCh := make(chan int, 3) // Buffered channel with capacity 3

    fmt.Println("Using Normal Channel:")
    go producer(normalCh)
    consumer(normalCh)

    time.Sleep(2 * time.Second) // Wait for the producer to finish

    fmt.Println("\nUsing Buffered Channel:")
    go producer(bufferedCh)
    consumer(bufferedCh)
}

Using Normal Channel:
Producing 1
Consuming 1
Producing 2
Consuming 2
Producing 3
Consuming 3
Producing 4
Consuming 4
Producing 5
Consuming 5

Using Buffered Channel:
Producing 1
Consuming 1
Producing 2
Consuming 2
Producing 3
Producing 4
Consuming 3
Producing 5
Consuming 4
Consuming 5

Youtube Channel: https://www.youtube.com/@codepiper
Github Link: https://github.com/arshad404/CodePiper/tree/main/GO/concurrency-patterns/Basics

Go: Efficient Marshalling & Unmarshalling

CodePiper — Wed, 19 Jul 2023 03:03:49 +0000

If you like to see the video on this blog, then here is the link of the video: https://www.youtube.com/watch?v=FCID6eezGTU

As a developer it is our day-to-day job converting the data from the byte type (received from the network wire in the form of response) to your API response struct. In this blog we will see how we can do that efficiently and in a optimized manner(consume low CPU and Memory)

I will compare two libraries, SONIC and JSON and will perform the benchmark test for these two libraries and check which is optimal for our use case.

Test Criteria:
The payload is divided into three parts.

Small size struct
Medium size struct
Large size struct
Extra Large size struct

*About the operation: *
It will consist a method which is performing two operations, first marshalling and then unmarshalling.

func MarshallingUnmarshallingJSON(t1 []album) {
    var result []*album
    byteReponse, _ := json.Marshal(t1)
    json.Unmarshal(byteReponse, &result)
}

func MarshallingUnmarshallingSONIC(t1 []album) {
    var result []album
    byteReponse, _ := sonic.Marshal(t1)
    sonic.Unmarshal(byteReponse, &result)
}

Result array size lies in four categories, and the benchmark result is as follows:

func BenchmarkJSON(b *testing.B) {
    // Small, Medium, Large, Extra Large
    var input = []int{10, 50, 100, 400}

    for _, v := range input {
        albums := BuildResponse(v)
        b.Run(fmt.Sprintf("input_size_%d", v), func(b *testing.B) {
            for i := 0; i < b.N; i++ {
                MarshallingUnmarshallingJSON(albums)
            }
        })
    }
}

func BenchmarkSonic(b *testing.B) {
    // Small, Medium, Large, Extra Large
    var input = []int{10, 50, 100, 400}

    for _, v := range input {
        albums := BuildResponse(v)
        b.Run(fmt.Sprintf("input_size_%d", v), func(b *testing.B) {
            for i := 0; i < b.N; i++ {
                MarshallingUnmarshallingSONIC(albums)
            }
        })
    }
}

And the results after benchmark test are as follows:

SONIC

Name	Operation	ns/op	B/op	allocs/op
BenchmarkSonic/input_size_10-4	184616	10799 ns/op	3787 B/op	11 allocs/op
BenchmarkSonic/input_size_50-4	39327	31660 ns/op	15188 B/op	12 allocs/op
BenchmarkSonic/input_size_100-4	20794	55688 ns/op	34839 B/op	13 allocs/op
BenchmarkSonic/input_size_400-4	5713	213816 ns/op	130859 B/op	14 allocs/op

JSON

Name	Operation	ns/op	B/op	allocs/op
BenchmarkJSON/input_size_10-4	21874	57925 ns/op	2689 B/op	57 allocs/op
BenchmarkJSON/input_size_50-4	4152	273070 ns/op	12053 B/op	265 allocs/op
BenchmarkJSON/input_size_100-4	2942	390126 ns/op	24157 B/op	519 allocs/op
BenchmarkJSON/input_size_400-4	930	1406397 ns/op	96853 B/op	2025 allocs/op

In all dimensions, SONIC is the clear winner and recommended for the use as it saves your memory and CPU.

Youtube Channel: https://www.youtube.com/@codepiper