Montreal police deployed a bomb squad and ordered an evacuation of certain buildings in an east-end neighbourhood Friday afternoon after a resident claimed to have found sticks of dynamite.

Objects found outside residential building were not dynamite sticks: Montreal police | CTV News

Officials are live at the scene of a planned detonation in Holladay.

WATCH: Loud boom heard as officials detonate Holladay home with stash of dynamite

Synamate

synamate

Building an API with Go, PostgreSQL, Google Cloud and CockroachDB

Understanding sync.Cond in Go: A Guide for Beginner's

গো-তে sync.Cond বোঝা: শিক্ষানবিসদের জন্য একটি নির্দেশিকা৷

sync.Cond in Go verstehen: Ein Leitfaden für Anfänger

Comprender sync.Cond in Go: una guía para principiantes

Comprendre sync.Cond in Go : un guide pour les débutants

Go में sync.Cond को समझना: शुरुआती लोगों के लिए एक गाइड

Goのsync.Condを理解する:初心者向けガイド

Go의 sync.Cond 이해: 초보자를 위한 가이드

Compreendendo o sync.Cond in Go: um guia para iniciantes

Понимание sync.Cond в Go: руководство для начинающих

Go'da Sync.Cond'u Anlamak: Yeni Başlayanlar İçin Bir Kılavuz

Tìm hiểu về sync.Cond in Go: Hướng dẫn dành cho người mới bắt đầu

理解 Go 中的 sync.Cond：初学者指南

Mastering Maps in Go: Everything You Need to Know

গো-তে মানচিত্র আয়ত্ত করা: আপনার যা জানা দরকার

Maps in Go meistern: Alles, was Sie wissen müssen

Dominar mapas en Go: todo lo que necesitas saber

Maîtriser les cartes en Go : tout ce que vous devez savoir

गो में मानचित्रों पर महारत हासिल करना: वह सब कुछ जो आपको जानना चाहिए

Go でマップをマスターする: 知っておくべきことすべて

Go로 지도 마스터하기: 알아야 할 모든 것

Dominando mapas em Go: tudo o que você precisa saber

Освоение карт в Go: все, что вам нужно знать

Go'da Haritalarda Uzmanlaşmak: Bilmeniz Gereken Her Şey

Làm chủ bản đồ trong Go: Mọi thứ bạn cần biết

掌握 Go 中的 Maps：你需要知道的一切

Sound Call Graph Construction for Java Object: Conclusions, Acknowledgment, & References

FlutBuffers in 2024: Can We Recreate Old Success? Performance Optimization Takes Center Stage!

Introduction In developing large-scale systems, it is always essential to think about resilience. The load on an application typically varies over time based on the number of active users or the types of activities they are performing. One of the most common situations you will encounter sooner or later is server overload caused by unanticipated bursts in traffic. It happens because every server has functional limitations. That means the server has limited network and computational resources like CPU and memory, so the server can effectively handle only a certain number of requests. When the number of requests reaches some threshold and continues growing, it increases resource utilization, leading to higher latency and reducing availability. There are many strategies to handle that situation. For instance, you can run several instances of your application and use autoscaling to match the provisioned resources to the users's needs at any time. However, when the amount of traffic is incredibly huge, scaling out may take time, and may be overloaded or fail. I will discuss common strategies to prevent such a situation in this article. servers Causes leading to traffic spikes There may be many reasons leading to the sudden traffic spikes. Let's consider some of the common. An application can experience sudden spikes in traffic due to events like breaking news, product launches, or promotional campaigns. If the servers are not prepared to handle this surge of traffic, they can quickly become overloaded. Also, when the traffic to the application is dropped temporarily for some reason, the application scales down. Then, when the traffic returns, the application can't scale out fast, leading to server overload and even failure. Another common reason is that malicious bots, or malware, can flood a server with requests, effectively overwhelming its resources. It is known as a distributed denial-of-service (DDoS) attack. Strategies to prevent service overload There are two main strategies to prevent server overload: Throttling, Load shedding. Throttling controls the consumption of resources used by an instance of an application, an individual user, or an entire service. For example, a server experiencing high demand may start throttling requests, slowing them down, or rejecting them until the load subsides. It allows the system to handle the incoming traffic without crashing or becoming unresponsive. One common technique for throttling is rate limiting, which defines the maximum number of requests a user, a client, or an entire group can make within a specific time frame, ensuring no single client or user can monopolize system resources. It is a proactive measure that aims to prevent the system from reaching its capacity in the first place. For instance, a rate limiter may allow 100 requests from a given IP address per minute. Exceeding this limit could result in the user being temporarily blocked or having their requests queued until they are within the allowable rate. Load shedding is a more drastic technique. It involves intentionally dropping requests to prevent a server from becoming overloaded. It is only done as a last resort when other measures, such as rate limiting, have proven insufficient. By shedding requests from one application instance, the load can be redistributed to other application instances in the cluster, preventing any single instance from reaching its limits. An example of rate-limiting Several algorithms can be used to implement rate limiters. Here, let's consider a basic implementation of a rate limiter using a token bucket algorithm, where tokens are added to the bucket at a fixed rate. The request is allowed if a token is available when a request is made. Otherwise, it is denied. This implementation can be applied to throttling requests from particular users, IP addresses, API keys, or other groups of users. main.go package main

import (
	"fmt"
	"log"
	"net/http"
	"sync"
	"time"
)

type bucket struct {
	remainingTokens int
	lastRefillTime  time.Time
}

type RateLimiter struct {
	maxTokens      int
	refillInterval time.Duration
	buckets        map[string]*bucket
	mu             sync.Mutex
}

func NewRateLimiter(rate int, perInterval time.Duration) *RateLimiter {
	return &RateLimiter{
		maxTokens:      rate,
		refillInterval: perInterval,
		buckets:        make(map[string]*bucket),
	}
}

func (rl *RateLimiter) IsLimitReached(id string) bool {
	rl.mu.Lock()
	defer rl.mu.Unlock()

	b, ok := rl.buckets[id]

	// If the bucket doesn't exist, it is the first request for this client.
	// Create a new bucket and allow the request.
	if !ok {
		rl.buckets[id] = &bucket{
			remainingTokens: rl.maxTokens - 1,
			lastRefillTime:  time.Now(),
		}
		return false
	}

	// Calculate the number of tokens to add to the bucket since the last
	// request.
	refillInterval := int(time.Since(b.lastRefillTime) / rl.refillInterval)
	tokensAdded := rl.maxTokens * refillInterval
	currentTokens := b.remainingTokens + tokensAdded

	// There is no tokens to serve the request for this client.
	// Reject the request.
	if currentTokens < 1 {
		return true
	}

	if currentTokens > rl.maxTokens {
		// If the number of current tokens is greater than the maximum allowed,
		// then reset the bucket and decrease the number of tokens by 1.
		b.lastRefillTime = time.Now()
		b.remainingTokens = rl.maxTokens - 1
	} else {
		// Otherwise, update the bucket and decrease the number of tokens by 1.
		deltaTokens := currentTokens - b.remainingTokens
		deltaRefills := deltaTokens / rl.maxTokens
		deltaTime := time.Duration(deltaRefills) * rl.refillInterval
		b.lastRefillTime = b.lastRefillTime.Add(deltaTime)
		b.remainingTokens = currentTokens - 1
	}

	// Allow the request.
	return false
}

type Handler struct {
	rl *RateLimiter
}

func NewHandler(rl *RateLimiter) *Handler {
	return &Handler{rl: rl}
}

func (h *Handler) Handler(w http.ResponseWriter, r *http.Request) {
	// Here should be the logic to get the client ID from the request 
	// (it could be a user ID, an IP address, an API key, etc.)
	clientID := "some-client-id"
	if h.rl.IsLimitReached(clientID) {
		w.WriteHeader(http.StatusTooManyRequests)
		fmt.Fprint(w, http.StatusText(http.StatusTooManyRequests))
		return
	}

	w.WriteHeader(http.StatusOK)
	fmt.Fprint(w, http.StatusText(http.StatusOK))
}

func main() {
	// We allow 1000 requests per second per client to our service.
	rl := NewRateLimiter(1000, 1*time.Second)
	h := NewHandler(rl)
	http.HandleFunc("/", h.Handler)
	log.Fatal(http.ListenAndServe(":8080", nil))
} Let's run our example using Docker Compose with configured for a container. Also, we will use , a benchmarking tool, to check how our application works on different loads. We will use the following and : resource constraints bombardier Dockerfile docker-compose.yml Dockerfile FROM golang:1.21 AS build-stage
WORKDIR /code
COPY main.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o /service main.go
FROM gcr.io/distroless/base AS build-release-stage
WORKDIR /
COPY --from=build-stage /service /service
EXPOSE 8080
ENTRYPOINT ["/service"] docker-compose.yml services:
  rate_limiting:
    build: .
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          cpus: '.20'
          memory: 100M
        reservations:
          cpus: '0.10'
          memory: 50M Let's run our application using the following command: docker compose -f ./cmd/rate_limiting/docker-compose.yml up --build --force-recreate -d You can monitor the container resource usage using the following command: dcocker stats Let's run the bombardier with different settings and check the results in a separate terminal window. First, let's try sending 10000 requests with one concurrent connection. $ bombardier -c 1 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 1 connection(s)
 10000 / 10000 [===============================================================] 100.00% 859/s 11s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec       868.33     833.53    2684.45
  Latency        1.15ms     6.93ms    75.42ms
  HTTP codes:
    1xx - 0, 2xx - 10000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   151.93KB/s From the results, you can see that the request rate on average is less than 1000 requests per second, which is the maximum allowed rate, and all requests were processed successfully. Next,  let's try sending 10000 requests with 100 concurrent connections. $ bombardier -c 100 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 100 connection(s)
 10000 / 10000 [===============================================================] 100.00% 3320/s 3s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      3395.87    6984.32   32322.59
  Latency       28.02ms    37.61ms   196.95ms
  HTTP codes:
    1xx - 0, 2xx - 3000, 3xx - 0, 4xx - 7000, 5xx - 0
    others - 0
  Throughput:   675.35KB/s You can see that the server started to return HTTP 429 status code, which means the server is overloaded due to many requests. Clean up your environment using the following command after all tests are done: docker compose -f ./cmd/rate_limiting/docker-compose.yml down --remove-orphans --timeout 1 --volumes An example of load-shedding Depending on your particular case, you can use different approaches to load shedding: Dropping random requests when the system becomes overloaded, Using a load balancer to distribute the load evenly, Monitoring server load continuously and dropping or rejecting requests when a certain load level is reached, Monitoring system metrics like CPU utilization, network I/O, or memory usage and dropping requests when these metrics reach certain thresholds, Set up priority levels for requests and start refusing low-priority requests when the system is under load, Etc. Load shedding can be implemented at various levels, including load balancers, servers, and software libraries. It requires careful planning and implementation, as poorly implemented load shedding can result in important requests being dropped, causing a negative impact on user experience or system functionality. Let's implement a simple load-shedding mechanism by detecting request overload conditions and responding with an HTTP 503 status code. main .go package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"sync/atomic"
	"time"
)

type LoadShedder struct {
	isOverloaded atomic.Bool
}

func NewLoadShedder(ctx context.Context, checkInterval, overloadFactor time.Duration) *LoadShedder {
	ls := LoadShedder{}

	go ls.runOverloadDetector(ctx, checkInterval, overloadFactor)

	return &ls
}

func (ls *LoadShedder) runOverloadDetector(ctx context.Context, checkInterval, overloadFactor time.Duration) {
	ticker := time.NewTicker(checkInterval)
	defer ticker.Stop()

	// Start with a fresh start time.
	startTime := time.Now()
	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			// Check how long it took to process the last batch of requests.
			elapsed := time.Since(startTime)
			if elapsed > overloadFactor {
				// If it took longer than the overload factor, we're overloaded.
				ls.isOverloaded.Store(true)
			} else {
				// Otherwise, we're not overloaded.
				ls.isOverloaded.Store(false)
			}
			// Reset the start time.
			startTime = time.Now()
		}
	}
}

func (ls *LoadShedder) IsOverloaded() bool {
	return ls.isOverloaded.Load()
}

type Handler struct {
	ls *LoadShedder
}

func NewHandler(ls *LoadShedder) *Handler {
	return &Handler{ls: ls}
}

func (h *Handler) Handler(w http.ResponseWriter, r *http.Request) {
	if h.ls.IsOverloaded() {
		w.WriteHeader(http.StatusServiceUnavailable)
		fmt.Fprint(w, http.StatusText(http.StatusServiceUnavailable))
		return
	}

	w.WriteHeader(http.StatusOK)
	fmt.Fprint(w, http.StatusText(http.StatusOK))
}

func main() {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	// The load shedder will check every 100ms if the last batch of requests
	// took longer than 200ms.
	ls := NewLoadShedder(ctx, 100*time.Millisecond, 200*time.Millisecond)

	h := NewHandler(ls)
	http.HandleFunc("/", h.Handler)

	log.Fatal(http.ListenAndServe(":8080", nil))
} We define the struct to run the load detector used in our request handler to check if we should return the HTTP 503 status code or process the request. The struct has an atomic flag indicating if the system is overloaded. We use atomic boolean value to make it thread-safe. We also have the method that returns the current value of the flag. In the function, we create a new and run the overload detector in a goroutine that checks according to the specified interval if the system is overloaded based on the overload factor. We check how much time has passed since the last check. If it is higher than the overload factor, the system is overloaded. That means that our request handler used resources for too long, and we need more capacity to handle the requests. LoadShedder LoadShedder IsOverloaded NewLoadShedder LoadShedder Let's run our example using. We will use the following and : Dockerfile docker-compose.yml Dockerfile FROM golang:1.21 AS build-stage
WORKDIR /code
COPY main.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o /service main.go
FROM gcr.io/distroless/base AS build-release-stage
WORKDIR /
COPY --from=build-stage /service /service
EXPOSE 8080
ENTRYPOINT ["/service"] docker-compose.yml services:
  load_shedding:
    build: .
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          cpus: '.20'
          memory: 100M
        reservations:
          cpus: '0.10'
          memory: 50M Let's run our application using the following command: docker compose -f ./cmd/load_shedding/docker-compose.yml up --build --force-recreate -d You can monitor the container resource usage using the following command: dcocker stats Let's run the bombardier with different settings and check the results in a separate terminal window. First, let's try sending 10000 requests with 10 concurrent connections. $ bombardier -c 10 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 10 connection(s)
 10000 / 10000 [===============================================================] 100.00% 1346/s 7s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      1389.49    1582.00    6284.42
  Latency        7.24ms    22.41ms    98.43ms
  HTTP codes:
    1xx - 0, 2xx - 10000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   242.78KB/s The results show that the maximum latency is less than 100 ms, and all requests were processed successfully. Next, let's try sending 10000 requests with 1000 concurrent connections. $ bombardier -c 1000 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 1000 connection(s)
 10000 / 10000 [===============================================================] 100.00% 3791/s 2s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      4242.28   11985.30   58592.64
  Latency      211.67ms   210.89ms      1.54s
  HTTP codes:
    1xx - 0, 2xx - 8823, 3xx - 0, 4xx - 0, 5xx - 1177
    others - 0
  Throughput:   696.96KB/s You can see that the server started to return HTTP 503 status code, which means the server is overloaded due to many requests, and you can see the maximum latency is more than 1 second. Clean up your environment using the following command after all tests are done: docker compose -f ./cmd/load_shedding/docker-compose.yml down --remove-orphans --timeout 1 --volumes Conclusion In this article, we discussed the causes leading to traffic spikes and strategies to prevent server overload. We also implemented a simple rate limiter and load shedder to demonstrate how they work. You can find all the code from the article here . https://github.com/ivanlemeshev/resilience For the production environment, you can use ready-to-use rate limiters like or . https://pkg.go.dev/golang.org/x/time/rate https://github.com/uber-go/ratelimit

How To Prevent Server Overload In Go

As you hopefully know from reading some of my recent articles, I really enjoy writing Kubernetes operators! I've written and also just recently about how to build them at the inaugural in Portland, Oregon. So here goes another operator-related article, although this one is about one of the later stages of operator development: performance tuning. a bit about them on this blog presented a talk FOSSY conference Since I've been working on an operator that includes multiple controllers, each with four reconcilers running concurrently that make API calls to resources outside of the cluster, I wanted to start profiling my reconciliation loop performance to ensure that I could handle real-world throughput requirements. Prometheus Metrics offers as part of its default scaffolding. This provides a great way to profile and monitor your operator's performance under both testing and live conditions. Kubebuilder the ability to export operator-specific Prometheus metrics Some of these metrics (many on a per-controller basis) include: A histogram of reconcile times Number of active workers Workqueue depth Total reconcile time Total reconcile errors API server request method & response counts Process memory usage & GC performance I wanted a way to monitor these metrics for controllers that are under development on my local machine. This means that they are running as processes outside of any cluster context, which makes it difficult to scrape their exposed metrics using a standard Prometheus/grafana setup. operator-prom-metrics-viewer So I thought, why not craft a little GUI to display this information? Inspired by the absolutely incredible , I decided to make a terminal-driven GUI using the . k9s project tview library Since I'm not (yet) storing this information for further analysis, I decided to only display the latest scraped data point for each metric. But I also didn't want to implement my own Prometheus metric parser to do this, so I imported pieces of the Prometheus to handle the metric parsing. All I had to do was implement a few interfaces for storing and querying my metrics to interop with the scrape library. scrape library itself Prometheus in-memory, transient storage The Prometheus storage and query interfaces are relatively simple, and it helps that we actually don't need to implement all of their methods! Storage The underlying storage mechanism of my class is a simple map along with a mutex for locking it during multithreaded IO. In this map, we are only storing the latest value for each metric, so there's no problem overwriting a key's value if it already exists. And we also don't need to worry about out-of-order writes or any other time-series database problems. InMemoryMetricStorage type InMemoryAppender struct {
	data map[uint64]DataPoint
	mu   *sync.Mutex
} The struct maps directly to a Prometheus metric's structure. If you've worked with Prometheus metrics before, this should look pretty familiar to you. DataPoint type DataPoint struct {
	Labels    labels.Labels
	Timestamp int64
	Value     float64
} To populate each DataPoint's key in the map, we can simply use the Prometheus builtin function to generate a unique key for each DataPoint, without having to do any extra work on our end. uint64 labels.Hash() To demonstrate, here's an example of a Prometheus metric: # HELP http_requests_total Total number of http api requests
# TYPE http_requests_total counter
http_requests_total{api="add_product"} 4633433 And how it would be represented by the struct: DataPoint d := DataPoint{
    Labels: []Label{
        {Name: "api", Value: "add_product"},
    },
    Value: 4633433,
    Timestamp: time.Now(),
} Now that we have our data model, we need a way to store s for further retrieval. DataPoint Appender Here's the interface of the storage backend appender: type Appender interface {
	Append(ref SeriesRef, l labels.Labels, t int64, v float64) (SeriesRef, error)
	Commit() error
	Rollback() error

	ExemplarAppender
	HistogramAppender
	MetadataUpdater
} Because we're building a simple in-memory tool (with no persistence or availability guarantees), we can ignore the and methods (by turning them into no-ops). Furthermore, we can avoid implementing the bottom three interfaces since the metrics that are exposed by Kubebuilder are not exemplars, metadata, or histograms (the framework actually uses gauges to represent the histogram values; more on this below!). So this only leaves the function to implement, which just writes to the 's underlying map storage in a threadsafe manner. Commit() Rollback() Append() InMemoryAppender func (a *InMemoryAppender) Append(ref storage.SeriesRef, l labels.Labels, t int64, v float64) (storage.SeriesRef, error) {
	a.mu.Lock()
	defer a.mu.Unlock()
	a.data[l.Hash()] = DataPoint{Labels: l, Timestamp: t, Value: v}
	return ref, nil
} Querier The querier implementation is also fairly straightforward. We just need to implement a single method against our datastore to extract metrics from our store. Query My solution is far from an optimized inner loop; it has awful exponential performance in the worst case. But for looping through a few metrics at a rate of at most once per second, I'm not overly concerned with the time complexity of this function. func (a *InMemoryAppender) Query(metric string, l labels.Labels) []DataPoint {
	a.mu.Lock()
	defer a.mu.Unlock()

	dataToReturn := []DataPoint{}

	for _, d := range a.data {
		if d.Labels.Get("__name__") != metric {
			continue
		}

		var isMatch bool = true
		for _, label := range l {
			if d.Labels.Get(label.Name) != label.Value {
				isMatch = false
			}
		}

		if isMatch {
			dataToReturn = append(dataToReturn, d)
		}

	}

	return dataToReturn
} Histogram implementation Since the controller reconcile time histogram data is stored in Prometheus gauges, I did need to write some additional code to transform these into a workable schema to actually generate a histogram. To aid in the construction of the histogram buckets, I created 2 structs, one to represent the histogram itself, and the other to represent each of its buckets. type HistogramData struct {
	buckets []Bucket
	curIdx  int
}

type Bucket struct {
	Label string
	Value int
} For each controller, we can run a query against our storage backend for the metric with the label. This will return all histogram buckets for a specific controller, each with a separate label ( ) that denotes the bucket's limit. We can iterate through these metrics to create objects, append them to the slice, and eventually sort them before rendering the histogram to keep the display consistent and in the correct order. workqueue_queue_duration_seconds_bucket name=<controller-name> le Bucket HistogramData.buckets The field on the struct is only used internally when rendering the histogram, to keep track of the current index of the slice that we're on. This way, we can consume buckets using a loop and exit when we return the final bucket. It's a bit clunky, but it works! curIdx HistogramData buckets for v1.0 After all of this hacking, I ended up with something that looks like this: It's far from perfect; since I don't manipulate the histogram values (yet) or have any display scrolling, it's very likely that the histogram will spill off the right of the screen. The UX can also be improved since you can only switch the controller that is being displayed by pressing the and buttons. Up Down But it's been a fantastic tool for me when debugging slow reconciles due to API rate limiting, and it has also highlighted errors for me when I miss them in the logs. Give it a whirl, and let me know what you think! Link to the GitHub: https://github.com/sklarsa/operator-prom-metrics-viewer Also published . here

Operator Performance Tuning: Building a GUI for Prometheus Metrics Visualization in Kubernetes

114 Stories To Learn About Piracy

100 Stories To Learn About Online Piracy

The Problem Periodically, when you are developing a Golang application, there is a need to store some data in memory using a map data structure. At the same time, the application can concurrently process a large number of requests and use the map in several goroutines concurrently. If you do not use any mechanisms of synchronization, the code fails with panic in runtime in that case. It is important to think of concurrent access to the map and data races. In this article, I want to consider several ways to solve this problem. Golang has built-in synchronization primitives and channels that can be used for that. Depending on the specific case, you can use different approaches. I am going to create the call counter which is a simple component that counts the number of times a method is called and the counters will be stored in a map. To begin with, let's define a simple interface that will have two methods. CallCounter The method will update the counter when the method is called, and the method will return the current value for the given method name. Call Count package callcounter

type CallCounter interface {
	Call(name string)
	Count(name string) int64
} Now, let's consider different implementations. sync.Mutex is a mutual exclusion lock. It is a synchronization primitive that allows concurrent goroutines to access shared data safely. A mutex ensures that only one goroutine can access the shared data at a time, preventing data races and other concurrency problems. sync.Mutex To use a , you must first lock it before accessing the map to shared data. Once you are finished accessing the shared data, you must unlock the mutex. If another goroutine tries to lock the mutex while it is already locked, it will be blocked until the mutex is unlocked. sync.Mutex Here is an implementation using : sync.Mutex package callcounter

import (
	"sync"
)

type CallCounterMutex struct {
	sync.Mutex
	counters map[string]int64
}

func NewCallCounterMutex() *CallCounterMutex {
	c := CallCounterMutex{
		counters: make(map[string]int64),
	}

	return &c
}

func (c *CallCounterMutex) Call(name string) {
	c.Lock()
	c.counters[name]++
	c.Unlock()
}

func (c *CallCounterMutex) Count(name string) int64 {
	c.Lock()
	count := c.counters[name]
	c.Unlock()

	return count
} sync.RWMutex is a read-write mutual exclusion lock. It is a synchronization primitive that allows multiple goroutines to concurrently read shared data, but only one goroutine to write shared data at a time. This is useful for situations where you need to allow concurrent reads, but not concurrent writes to shared data. sync.RWMutex To use a , you must first lock it for reading and writing using the and methods, respectively. Once you are finished accessing the shared data, you must unlock the mutex using the or methods, respectively. sync.RWMutex RLock Lock RUnlock Unlock If another goroutine tries to lock the mutex for reading while it is locked for writing, it will be blocked until the mutex is unlocked. Similarly, if another goroutine tries to lock the mutex for writing while it is locked for reading, it will be blocked until the mutex is unlocked. Here is an implementation using : sync.RWMutex package callcounter

import (
	"sync"
)

type CallCounterRWMutex struct {
	sync.RWMutex
	counters map[string]int64
}

func NewCallCounterRWMutex() *CallCounterRWMutex {
	c := CallCounterRWMutex{
		counters: make(map[string]int64),
	}

	return &c
}

func (c *CallCounterRWMutex) Call(name string) {
	c.Lock()
	c.counters[name]++
	c.Unlock()
}

func (c *CallCounterRWMutex) Count(name string) int64 {
	c.RLock()
	count := c.counters[name]
	c.RUnlock()

	return count
} sync.Map is a concurrent map implementation in Golang. It is a specialized map implementation that provides a concurrent, thread-safe map. It is specifically designed for use cases where the entry set of the map is stable over time, such as caches. sync.Map is a safe map, meaning that it can be accessed by multiple goroutines concurrently without the risk of race conditions or data corruption. It is also a fast map, with amortized constant-time loads, stores, and deletes. sync.Map Here is an implementation using : sync.Map package callcounter

import (
	"sync"
	"sync/atomic"
)

type CallCounterMap struct {
	sync.Map
}

func NewCallCounterMap() *CallCounterMap {
	c := CallCounterMap{}

	return &c
}

func (c *CallCounterMap) Call(name string) {
	value := int64(1)
	count, loaded := c.LoadOrStore(name, &value)
	if loaded {
		atomic.AddInt64(count.(*int64), int64(value))
	}
}

func (s *CallCounterMap) Count(name string) int64 {
	count, ok := s.Load(name)
	if ok {
		return atomic.LoadInt64(count.(*int64))
	}

	return 0
} Channels Channels are a powerful tool for communicating and synchronizing between concurrent goroutines. They are typed conduits through which you can send and receive values. To create a channel, you use the function. The function takes two arguments: the type of the values that the channel will transmit and the capacity of the channel. The capacity of the channel is the maximum number of values that the channel can store without blocking the sender. make make Channels allow us to write the code in a way where only one goroutine reads or writes to the map. Here is an implementation using channels: package callcounter

import "context"

type CallCounterChannels struct {
	counters map[string]int64
	call     chan string
	count    chan string
	result   chan int64
}

func NewCallCounterChannels(ctx context.Context) *CallCounterChannels {
	c := CallCounterChannels{
		counters: make(map[string]int64),
		call:     make(chan string),
		count:    make(chan string),
		result:   make(chan int64),
	}

	go func() {
		for {
			select {
			case <-ctx.Done():
				return
			case name := <-c.call:
				c.counters[name]++
			case name := <-c.count:
				c.result <- c.counters[name]
			}
		}
	}()

	return &c
}

func (c *CallCounterChannels) Call(name string) {
	c.call <- name
}

func (c *CallCounterChannels) Count(name string) int64 {
	c.count <- name

	return <-c.result
} Mutex Based on a Channel Also, Golang allows us to implement a simple mutex using channels. We need to use a buffered channel for that. A buffered channel in Golang is a channel that can store a limited number of values without blocking the sender. This is in contrast to an unbuffered channel, which can only store one value at a time and will block the sender if there is no receiver ready to receive the value. Buffered channels are created by passing an additional capacity parameter to the function. This parameter specifies the maximum number of values that the channel can store. We need to create a buffered channel that can store exactly one value. make It will allow us to use this channel to lock and unlock goroutines because when the buffered channel is full, it blocks other goroutines from writing into it, and they will wait until it is free. Here is an implementation using a buffered channel: package callcounter

type CallCounterChannelMutex struct {
	counters map[string]int64
	mutex    chan struct{}
}

func NewCallCounterChannelMutex() *CallCounterChannelMutex {
	c := CallCounterChannelMutex{
		counters: make(map[string]int64),
		mutex:    make(chan struct{}, 1),
	}

	return &c
}

func (c *CallCounterChannelMutex) Call(name string) {
	c.mutex <- struct{}{}
	c.counters[name]++
	<-c.mutex
}

func (c *CallCounterChannelMutex) Count(name string) int64 {
	c.mutex <- struct{}{}
	count := c.counters[name]
	<-c.mutex
	return count
} Comparing and Testing Now, let's write a simple test to ensure that our code is correct, concurrent safe, and does not have data races. We will also write some benchmarks and compare the performance of different approaches. package callcounter_test

import (
	"callcounter"
	"context"
	"fmt"
	"sync"
	"testing"

	"github.com/stretchr/testify/assert"
)

func TestCallCounter(t *testing.T) {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	tt := []struct {
		name    string
		counter callcounter.CallCounter
		calls   []int
	}{
		{
			name:    "mutex",
			counter: callcounter.NewCallCounterMutex(),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "rwmutex",
			counter: callcounter.NewCallCounterRWMutex(),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "map",
			counter: callcounter.NewCallCounterMap(),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "channels",
			counter: callcounter.NewCallCounterChannels(ctx),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "mutex based on a channel",
			counter: callcounter.NewCallCounterChannelMutex(),
			calls:   []int{0, 1, 3, 100},
		},
	}

	for _, tc := range tt {
		for _, calls := range tc.calls {
			testName := fmt.Sprintf("%s %d calls", tc.name, calls)

			t.Run(testName, func(t *testing.T) {
				wg := sync.WaitGroup{}
				for i := 0; i < calls; i++ {
					wg.Add(1)

					// Run in goroutine to make sure
					// there is no any issue with concurrent counter.
					go func() {
						defer wg.Done()

						tc.counter.Call(testName)
					}()
				}

				wg.Wait()
				assert.Equal(t, int64(calls), tc.counter.Count(testName))
			})
		}
	}
}

var result int64

func BenchmarkCallCounter(b *testing.B) {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	tt := []struct {
		name    string
		counter callcounter.CallCounter
	}{
		{
			name:    "mutex",
			counter: callcounter.NewCallCounterMutex(),
		},
		{
			name:    "rwmutex",
			counter: callcounter.NewCallCounterRWMutex(),
		},
		{
			name:    "map",
			counter: callcounter.NewCallCounterMap(),
		},
		{
			name:    "channels",
			counter: callcounter.NewCallCounterChannels(ctx),
		},
		{
			name:    "mutex based on a channel",
			counter: callcounter.NewCallCounterChannelMutex(),
		},
	}

	var count int64

	for _, tc := range tt {
		b.Run(tc.name, func(b *testing.B) {
			wg := sync.WaitGroup{}
			for i := 0; i < b.N; i++ {
				wg.Add(1)
				go func() {
					defer wg.Done()

					tc.counter.Call("call_name")
				}()

				wg.Add(1)
				go func() {
					defer wg.Done()

					// Always record the result of Count to prevent
					// the compiler eliminating the function call.
					count = tc.counter.Count("call_name")
				}()
			}

			wg.Wait()

			// Always store the result to a package level variable
			// so the compiler cannot eliminate the Benchmark itself.
			result = count
		})
	}
} Let's run the tests using the flag : --race $ go test --race -v .
=== RUN   TestCallCounter
=== RUN   TestCallCounter/mutex_0_calls
=== RUN   TestCallCounter/mutex_1_calls
=== RUN   TestCallCounter/mutex_3_calls
=== RUN   TestCallCounter/mutex_100_calls
=== RUN   TestCallCounter/rwmutex_0_calls
=== RUN   TestCallCounter/rwmutex_1_calls
=== RUN   TestCallCounter/rwmutex_3_calls
=== RUN   TestCallCounter/rwmutex_100_calls
=== RUN   TestCallCounter/map_0_calls
=== RUN   TestCallCounter/map_1_calls
=== RUN   TestCallCounter/map_3_calls
=== RUN   TestCallCounter/map_100_calls
=== RUN   TestCallCounter/channels_0_calls
=== RUN   TestCallCounter/channels_1_calls
=== RUN   TestCallCounter/channels_3_calls
=== RUN   TestCallCounter/channels_100_calls
=== RUN   TestCallCounter/mutex_channel_0_calls
=== RUN   TestCallCounter/mutex_channel_1_calls
=== RUN   TestCallCounter/mutex_channel_3_calls
=== RUN   TestCallCounter/mutex_channel_100_calls
--- PASS: TestCallCounter (0.01s)
    --- PASS: TestCallCounter/mutex_0_calls (0.00s)
    --- PASS: TestCallCounter/mutex_1_calls (0.00s)
    --- PASS: TestCallCounter/mutex_3_calls (0.00s)
    --- PASS: TestCallCounter/mutex_100_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_0_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_1_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_3_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_100_calls (0.00s)
    --- PASS: TestCallCounter/map_0_calls (0.00s)
    --- PASS: TestCallCounter/map_1_calls (0.00s)
    --- PASS: TestCallCounter/map_3_calls (0.00s)
    --- PASS: TestCallCounter/map_100_calls (0.00s)
    --- PASS: TestCallCounter/channels_0_calls (0.00s)
    --- PASS: TestCallCounter/channels_1_calls (0.00s)
    --- PASS: TestCallCounter/channels_3_calls (0.00s)
    --- PASS: TestCallCounter/channels_100_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_0_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_1_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_3_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_100_calls (0.00s)
PASS
ok      github.com/ivanlemeshev/callcounter     1.014s Now, let’s run benchmark tests: $ go test -bench=. -benchmem -count 1
goos: linux
goarch: amd64
pkg: github.com/ivanlemeshev/callcounter
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkCallCounter/mutex-16            2054628               605.1 ns/op            79 B/op          2 allocs/op
BenchmarkCallCounter/rwmutex-16          1000000              1057 ns/op             174 B/op          2 allocs/op
BenchmarkCallCounter/map-16              3605562               363.4 ns/op            80 B/op          4 allocs/op
BenchmarkCallCounter/channels-16          593912              2483 ns/op             273 B/op          3 allocs/op
BenchmarkCallCounter/mutex_channel-16     492544              2310 ns/op             268 B/op          3 allocs/op
PASS
ok      github.com/ivanlemeshev/callcounter     7.923s The benchmark results show that the Mutex-based implementation is the fastest and most efficient implementation. It has the lowest operation time and the lowest memory allocation. The RWMutex-based implementation is a good alternative if you need to support concurrent reads and writes to the call counter. The map-based implementation is a good alternative if you need a fast call counter implementation, and you don't need to support concurrent writes. The channel-based implementation is the slowest and least efficient implementation in our case. Summary The results show that depending on the requirements, you should choose the approach that is most suitable for your particular case. It may be a bad idea to use only channels all the time. , , , and channels are synchronization primitives in Golang that can be used to protect shared data and coordinate the execution of goroutines. However, they have different strengths and weaknesses and should be used in different situations. sync.Mutex sync.RWMutex sync.Map Mutexes are a good choice for protecting shared data frequently accessed by concurrent goroutines. For example, you might use a mutex to protect a shared counter or a map. Channels are a good choice for coordinating the execution of goroutines that need to communicate with each other or synchronize their execution. For example, you might use channels to implement a producer-consumer pattern or to coordinate the execution of a pipeline of goroutines. can be used when you need a concurrent-safe map that is optimized for read-heavy workloads. is a specialized map implementation that provides a concurrent, thread-safe map. It is specifically designed for use cases where the entry set of the map is stable over time, such as caches. sync.Map sync.Map

How to Use Maps Safely in Go

Stories, News & Mentions about SYNAMATE

Synamate’s Stories on HackerNoon

Synamate's News & Mentions