DEV Community: Rahul Kumar

How does a server understand "hii"? The underneath mechanism of HTTP, WebSockets and WebRTC

Rahul Kumar — Tue, 06 Oct 2026 19:03:49 +0000

Why HTTP, WebSockets and WebRTC?

a simple walk from how people talk to how machines talk

Start with how we talk in real life

Two people talking need three things. First, a medium that carries the voice (air, or a phone line). Second, an address to reach the right person (their phone number). Third, a common language, so the words mean something.

Take a phone call. We dial a number, the call goes through towers and cables, and the friend picks up. The medium and the address are working perfectly. But if we say "kaise ho?" and the friend doesn't know Hindi, nothing happens. The voice reached him, but he can't understand it. If we say "how r u?", he understands and replies "I'm good".

The internet has exactly the same split, and almost everything in this topic comes from it. Some protocols carry the data (medium and address), and some protocols give the data meaning (language).

The carrying part: IP, TCP and UDP

Physical layer. Cables, wifi and 4G/5G towers turn bits into signals (radio waves, light, voltage) and move them. They don't care what the bits mean, just like the tower doesn't care what language we speak.

IP (IPv4 and IPv6). This is the phone number. Every machine gets an address like 142.250.77.46 (IPv4). IPv6 is the longer version, created because IPv4 addresses were running out. IP only delivers on a best-effort basis. A packet can get lost, duplicated, or arrive out of order, and IP won't tell anyone.

Ports. The IP address finds the machine, but one machine runs many apps. A port finds the right app (80 for HTTP, 443 for HTTPS), like an extension number after the main phone number.

TCP and UDP. Both sit on top of IP and use ports. They differ in how they deliver.

TCP is like a proper phone call. First we confirm the other side is there (the 3-way handshake: SYN, SYN-ACK, ACK). Then every chunk is numbered, the receiver confirms each one (ACK), anything lost is sent again, and everything is handed over in the right order.
UDP is like shouting a message across the street. No call setup, no confirmation, no re-sending. Some words may not arrive, but it is fast and light.

The important limit is this: TCP gives only a stream of bytes. It has no idea where one message ends and the next begins, or whether the bytes are a name, a photo, or hii. Just like the phone call, the connection is working, but the meaning is missing.

The language part: why HTTP?

When we send hii to a server, the server receives bits. A server is just a program, and it can't "understand" anything by itself. It can only read data in a format it was written to expect, and both sides must agree on that format beforehand. That agreement is a protocol, and for the web it is HTTP.

HTTP is a text format. A request looks like this:

GET /myprofile HTTP/1.1
Host: myapp.com
Authorization: Bearer <token>

The first line has three parts:

Method: what we want to do. GET is "give me something", POST is "create something" (like sending an email and password to make an account), PUT/PATCH update, and DELETE removes.
Path: what we want it done to (/myprofile).
Version: which dialect of HTTP we speak.

The headers add details such as who we are and what formats we accept. The server reads this, knows "ohh, I have to send the profile", runs its code, and replies in the same agreed format:

HTTP/1.1 200 OK
Content-Type: application/json

{"name": "Rahul", "age": 21}

The 200 is a status code that says how it went. 404 means not found, 401 means not logged in, and 500 means the server crashed.

That is the whole answer to "why HTTP": TCP made the call, and HTTP is the language that tells the server what the client wants. This is the same as "how r u" telling the friend what to answer. Two details are worth knowing:

HTTP is stateless. Each request stands alone, and the server doesn't remember the previous one by itself. That is why cookies, sessions and tokens exist.
HTTP/1.1 and HTTP/2 run on TCP. HTTP/3 runs on QUIC, which is built on UDP with reliability added on top. So "HTTP means TCP" is the common case, not a law.
HTTPS is the same HTTP wrapped in TLS, which encrypts it.

HTTP only answers, it never starts the talk

HTTP follows the client-server model with a strict rule: request first, response after. GET /myprofile makes the server send the profile. POST with an email and password makes the server create the account. The server never does anything on its own. It can't say "hey, new message!" unless a request is there to answer.

For loading a profile or checking a balance, this is perfect. But what about a chat? We asked a friend something, and now we want to know whether he has replied. The server won't tell us, so we have to ask.

Polling: asking again and again

Short polling means sending a request every fixed interval, say every 2 seconds, with the question "any new message?". Each time, the server queries the database and replies, and most of the time the answer is "nothing". Why this hurts:

Each request carries full HTTP headers in both directions, often hundreds of bytes with cookies and tokens.
Each one makes the server run its code and hit the database.
The reply can still be up to 2 seconds late, because a message that arrives just after a check waits for the next one.
At scale it is huge. One million users polling every 2 seconds is 500,000 requests per second, nearly all of them returning nothing.

Throttling is how servers protect themselves from this. The server (or a gateway in front of it) limits how many requests one client may send, for example 100 per minute. If we cross it, we get 429 Too Many Requests. So throttling is a deliberate limit on the client's requests, not the server slowing itself down.

Long polling: let the server wait

Instead of the server answering "nothing" immediately, what if it just holds our request open? The client asks "any new message?". If there isn't one, the server doesn't reply yet. It parks the request and replies only when a message arrives, or when a timeout (typically 20 to 60 seconds) runs out and it sends an empty reply. In both cases, the client sends the next request immediately, so there is nearly always one waiting request at the server.

How does the server wait without wasting effort? It doesn't loop and keep checking the database, since that would only move the waste inside the server. It uses event-driven programming: the handler registers "wake me when a message arrives for this user" and goes to sleep. When a message arrives, an event fires and the server completes the waiting request. This is why event-driven runtimes (Node's event loop, async I/O, epoll) can hold thousands of parked connections cheaply.

This fixes much of the waste and the delay, but it is only a partial fix:

Every message still costs one full request and response, with all the headers.
After every reply, the client has to reconnect.
It is still effectively one-directional. While a request is parked, sending our own message needs a second request.
Proxies and load balancers may cut long-held connections, and messages arriving between one reply and the next request must be remembered by the server so they aren't missed.

WebSockets: one connection, both directions

The real fix is to stop making a new request for every message. Open one connection and keep it open for the whole chat, so that either side can send whenever it wants. This is called full-duplex communication, and it is what WebSockets give us.

A WebSocket doesn't replace HTTP completely. It starts with HTTP, once, to open the door. The client sends a normal HTTP request asking to switch protocols:

GET /chat HTTP/1.1
Host: myapp.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

If the server agrees, it answers:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

101 Switching Protocols means "agreed". The Sec-WebSocket-Accept value is calculated from the client's key, proving the server really understands WebSocket. Starting as HTTP also helps because the connection passes through the same ports (80 and 443) and proxies that already handle web traffic.

After that exchange, the same TCP connection stops speaking HTTP. Both sides now send small frames (text, binary, ping, pong or close) with a header of only 2 to 14 bytes, instead of hundreds of bytes of HTTP headers on every message.

What this gives us:

The server can push: "your friend replied" arrives the moment it exists, without any request.
No repeated headers, no reconnecting, no empty replies.
URLs are ws:// (plain) and wss:// (encrypted with TLS, the one used in production).
Ping/pong frames check the connection is alive, because silent connections get dropped by routers and proxies.
The trade-off is that the server now holds state for every open connection. Scaling across several servers needs an extra layer (like Redis pub/sub) to deliver a message to whichever server holds the receiver's connection.
If only the server needs to push (notifications, live scores), Server-Sent Events is a lighter one-way option over plain HTTP.

WebRTC: when TCP's reliability becomes the problem

WebSockets are great for chat because every message must arrive, and in order. That is exactly what TCP guarantees. But live voice and video are different.

Suppose a packet is lost. TCP will not hand later packets to the app until the missing one is re-sent, even if they have already arrived. This is head-of-line blocking. For a download, that is correct. For a live call it is a disaster, because by the time the re-sent packet arrives, that moment of the conversation is 300 ms old and useless. The call doesn't show an error. It freezes and lags, then rushes to catch up.

So for live media we want UDP: if a few milliseconds of voice are lost, skip them and keep going. For a call, fresh and slightly broken is better than perfect and late.

That is why WebRTC exists. It isn't one protocol but a bundle that lets two browsers or apps talk peer-to-peer, directly and not through our server:

Signaling: before the call, the two sides must exchange who they are, which codecs they support (SDP offer and answer), and how to reach each other (ICE candidates). WebRTC doesn't define how to carry this, so apps usually use a WebSocket or HTTP through a signaling server. That is why WebSockets and WebRTC often appear together.
NAT traversal: most devices sit behind a router with a private address, so they can't just dial each other. A STUN server tells each peer its public address. If a direct path is impossible (strict firewalls), a TURN server relays the media instead.
Media: audio and video travel as SRTP (encrypted RTP) over UDP. Arbitrary data (chat, files, game state) travels over data channels using SCTP over DTLS, also on UDP.
Because UDP gives no help, WebRTC adds its own lightweight control: sequence numbers, a jitter buffer to smooth uneven arrival, congestion control to lower quality on a bad network, and optional re-sends only for important video frames.

Why not WebSockets over UDP?

This question comes up naturally, and the answer has four parts:

WebSocket is defined on top of TCP. It begins with an HTTP upgrade, and its frame format assumes bytes arrive complete and in order. It can't survive packet loss, so a "WebSocket over UDP" would really be a different protocol.
Browsers don't allow raw UDP sockets. A page that could send arbitrary UDP packets could be used for attacks and network scanning. WebRTC is the controlled exception, with built-in encryption and a check that the other side agreed to receive.
Raw UDP gives none of the extras. NAT traversal, encryption, congestion control, jitter buffering and codecs would all have to be built from scratch. WebRTC ships them together.
They are built for different jobs. Chat, notifications and live dashboards need every message in order, so TCP's guarantees are a feature there.

A newer option is WebTransport, which runs over HTTP/3 (QUIC, built on UDP). It gives browsers both reliable streams and unreliable datagrams, a bit like a "WebSocket that can also skip reliability".

The whole story in one list

Load a profile, create an account: use HTTP. One request, one response. Only the client can start.
Check for news on a timer: use short polling. Repeated requests, mostly empty replies. Only the client can start.
Check for news, with less waste: use long polling. The request is parked until data arrives. Only the client can start (the server replies late).
Live chat, notifications, live scores: use WebSocket. One TCP connection kept open, data sent as frames. Both sides can start.
Live voice, video, games: use WebRTC. Peer-to-peer, mostly over UDP. Both sides can start.

In one line each

IP, TCP and UDP are the phone line: they carry the bits.
HTTP is the language: it gives the bits a meaning (GET /myprofile = send my profile).
Polling and long polling are workarounds for HTTP only answering when asked.
WebSocket keeps the line open so both sides can speak anytime.
WebRTC gives up TCP's guarantees on purpose, because in a live call, a late word is worth less than a missing one.

Fundamentals of redis(caching), why we use REDIS? or origin of it

Rahul Kumar — Sat, 03 Oct 2026 17:00:44 +0000

Part 1: Computer basics
CPU (Central Processing Unit)
Definition: The chip that executes instructions (calculations, comparisons, running your code).
Simple meaning: The brain that does the work.
Example: Parsing a request, running a loop, or computing a sum is CPU work.
RAM (Random Access Memory)
Definition: Fast, temporary memory where a running program keeps the data it is using right now.
Simple meaning: The desk where you keep the papers you're working on.
Example: Variables, arrays and maps in your code live in RAM.
SSD (Solid State Drive)
Definition: Permanent storage with no moving parts. Data stays when power is off.
Simple meaning: The cupboard where you store papers for the long term.
Example: Your files, installed apps, and database files.
Volatile vs Persistent
Volatile: data is lost when power is off or the process restarts (RAM).
Persistent: data survives restarts and power loss (SSD).
Latency
Definition: The time one operation takes from start to finish.
Simple meaning: How long you wait for one answer.
Operation Rough latency
Read from RAM ~100 nanoseconds
Read from SSD ~100 microseconds
Network call to Redis ~0.5 to 1 millisecond
Database query ~5 to 50 milliseconds (varies a lot)

(1 millisecond = 1,000 microseconds = 1,000,000 nanoseconds)

Yes, your laptop, EC2 server and database server all have CPU, RAM and SSD.

Part 2: Why a local map works on your laptop but breaks in production
Hash map (map / dictionary)
Definition: A data structure that stores data as key → value pairs and finds a value by its key very quickly (usually O(1)).
Simple meaning: A phonebook: look up the name (key), get the number (value).
Example: cache["user:42"] = {name: "Ravi"}
Cache
Definition: A fast storage layer that keeps copies of frequently used data so you don't have to fetch it from the slow source again.
Simple meaning: A shortcut. Keep answers you need often in RAM instead of asking the database every time.
Cache hit and cache miss
Cache hit: the data is found in the cache (fast).
Cache miss: the data is not in the cache, so you go to the database (slow), then usually save it to the cache.
Hit ratio: hits ÷ total requests. A higher ratio means a better cache.
Synchronous vs Asynchronous
Synchronous: one task finishes before the next starts.
Asynchronous: a task is started, and the program continues doing other things while waiting.

A single request on your laptop is simple, so a map works. Production is different because of concurrency.

Concurrency
Definition: Many tasks in progress at overlapping times.
Simple meaning: 100 users sending requests at the same moment.
Note: Concurrency is not the same as synchronous. Your server is concurrent. The problem isn't that one request is synchronous.
Thread and Goroutine
Thread: the smallest unit of execution the OS schedules. A server uses many threads to handle many requests.
Goroutine: Go's lightweight version of a thread, managed by Go itself. A web server in Go usually runs each request in its own goroutine.
Race condition
Definition: A bug where the result depends on the timing of two or more threads touching the same data.
Example: Two goroutines both read count = 5, both add 1, and both write 6. The answer should be 7. One update is lost.
Problem 1: Concurrent map access

In Go, writing to a map from two goroutines at once causes a fatal error (concurrent map writes) and the whole process crashes. (Node.js runs JS on one thread, so it doesn't crash this way, but logical races can still occur across await calls.)

Mutex (Mutual Exclusion lock)
Definition: A lock that allows only one goroutine at a time into a protected section of code.
Simple meaning: A bathroom key. Whoever has the key goes in, and everyone else waits.
sync.RWMutex (Read-Write mutex): many readers can read together (RLock), but a writer needs exclusive access (Lock).
Thread-safe: code that behaves correctly when used by many threads at once.
Note: A mutex doesn't make requests synchronous. It makes only the small locked part sequential.
Problem 2: Memory grows forever

A map has no size limit. Keep adding keys and RAM fills up.

OOM (Out Of Memory): the OS kills your process because RAM ran out.
Memory leak: memory that keeps growing and is never released.
Eviction and LRU
Eviction: automatically removing old data from a cache when it is full.
LRU (Least Recently Used): remove the item that hasn't been used for the longest time.
Other policies: LFU (Least Frequently Used), FIFO (First In First Out), random.
Problem 3: Stale data (you missed this)
TTL (Time To Live): a timer on a key. After it ends, the key is deleted automatically.
Stale data: a cached copy that is out of date compared to the database.
Example: SET user:42 data EX 60 means the key expires after 60 seconds.

To build a real cache by hand you need Mutex + LRU eviction + TTL. This is hard and bug-prone.

Part 3: Why not use the EC2 or RDS RAM as the cache?
Typical setup
EC2 (app server): runs your Go/Node code.
RDS (database server): runs PostgreSQL/MySQL.
Each has its own CPU, RAM and SSD. RAM is never shared between machines.
Load balancer
Definition: A component that spreads incoming requests across multiple servers.
Simple meaning: A traffic police officer sending each car to a different lane.
Horizontal scaling
Definition: Handling more traffic by adding more servers (instead of making one server bigger).
Vertical scaling: making one server bigger (more CPU/RAM).
Issue A: Each server has its own separate RAM
User A's data is cached on EC2 #1.
The next request goes to EC2 #2, which has nothing, so that's a cache miss.
The same data ends up cached 10 times.
Worse, the copies can disagree, which is called inconsistency. EC2 #1 has old data and EC2 #2 has new data.

For sessions, a miss means the user is logged out. For normal data, it only means an extra database trip.

Session: data the server remembers about a logged-in user between requests.
Issue B: Restarts wipe the cache

Deploys, crashes and auto-scaling erase RAM.

Cold cache: an empty cache after a restart.
Thundering herd (cache stampede): after a cold start, thousands of requests miss at once and all hit the database together.
Why not rely on RDS's own RAM?

RDS does cache data pages in RAM automatically. But a database is built for correctness, not raw speed:

ACID: Atomicity, Consistency, Isolation, Durability. Guarantees that transactions are safe and complete.
Durability: once committed, data is saved to disk even if power fails. This forces disk writes.
Query overhead: each query is parsed, planned and executed, with joins, filters and locks costing CPU.
Connection limit: a database allows only a limited number of simultaneous connections. A connection pool reuses connections to avoid opening new ones.
Hard to scale: adding database servers is much harder than adding app servers.

Under 100,000 simple queries, RDS typically doesn't crash. It slows down or runs out of connections, and then your whole app slows down.

Conclusion: We need one shared, central, in-memory cache that all EC2 servers talk to over the network. That is Redis.

Part 4: What is Redis?

Redis (REmote DIctionary Server) is an in-memory data store that works like a hash map running on its own server, accessible over the network. It has these features built in:

Thread-safe by design: Redis executes commands one at a time (single-threaded command execution), so no race conditions on your data.
Eviction policies: LRU, LFU, etc., so memory never grows forever.
TTL: keys expire automatically.
Shared: all EC2 servers see the same data.
Optional persistence: it can save data to disk to survive restarts.
Tradeoffs to know
Network cost: Redis is a separate server, so it's slower than local RAM (~1 ms vs ~100 ns), but far faster than the database.
Single point of failure (SPOF): if the one Redis server dies, everything depending on it breaks. The fix is replication (keeping copies on other servers).
Still volatile by default, unless persistence is enabled.
Cache invalidation: deciding when to delete or update cached data after the database changes. This is famously one of the hardest problems in computing.

I ran a small Go experiment to see how CPU cores affect performance.

Rahul Kumar — Fri, 02 Oct 2026 13:53:31 +0000

## 1. Understanding CPU cores at the system level

At the system level, the CPU is responsible for executing instructions. We have different numbers of CPU cores, such as 1 core, 2 cores, 4 cores, 8 cores, etc.

Each logical CPU can execute one thread at a time.

For example:

1 logical CPU → 1 thread executing at a time.
2 logical CPUs → 2 threads executing simultaneously.
4 logical CPUs → 4 threads executing simultaneously.

However, having more CPU cores does not automatically mean faster execution. It depends on how the application utilizes those cores and whether the workload can be executed in parallel.

2. Concurrency vs. Parallelism

Concurrency: Multiple tasks are in progress, but they don't necessarily execute simultaneously.

For example, on a single CPU core, the operating system can switch between multiple tasks. To humans, they may appear to be executing simultaneously because the switching happens very quickly.

Parallelism: Two or more tasks execute at the same time using separate execution resources, such as different CPU cores.

For example:

Task 1 executes on Core 1.
Task 2 executes on Core 2.

Both tasks are executing simultaneously.

Remember: Concurrency is about managing multiple tasks at once, whereas parallelism is about executing multiple tasks at the same instant.

3. How Go handles task execution

Go provides its own concurrency mechanism through goroutines and a runtime scheduler.

Goroutines

A goroutine is a lightweight execution unit managed by the Go runtime.

For example:

1 task → potentially 1 goroutine.
2 independent tasks → potentially 2 goroutines.
10,000 independent tasks → potentially 10,000 goroutines.

However, the number of goroutines depends on how we design our application. We don't necessarily need one goroutine for every individual job.

Go can efficiently manage thousands of goroutines without creating an equivalent number of OS threads.

OS Threads

OS threads are execution contexts managed by the operating system.

They are responsible for executing instructions on available logical CPUs.

Go's runtime manages the relationship between goroutines and OS threads.

GOMAXPROCS

GOMAXPROCS controls how many goroutines can execute Go code simultaneously.

By default, Go generally configures this according to the available CPU resources.

For example, if our system has 2 available logical CPUs:

Available CPUs: 2
GOMAXPROCS: 2

This means Go can execute Go code in parallel across up to 2 logical CPUs.

Important: GOMAXPROCS is not the number of OS threads Go creates. Go's runtime can create and manage more OS threads as needed.

4. Relationship between CPU cores, OS threads, and goroutines

Suppose our system has only 2 logical CPUs.

We can still have:

10 goroutines.
10 OS threads.
100 goroutines.
Even thousands of goroutines.

But having more threads or goroutines does not mean we have more physical CPU cores.

For example:

Available logical CPUs: 2
Goroutines: 4
GOMAXPROCS: 2

Go can execute up to 2 goroutines simultaneously, while the remaining goroutines wait for their turn or wait for some operation to complete.

The Go runtime schedules goroutines onto OS threads, and the operating system schedules those threads onto available logical CPUs.

5. Does having more threads make execution faster?

Sometimes yes, but not always.

It depends on the workload.

Case 1: CPU-intensive tasks

Suppose we are calculating prime numbers within a specific range.

This task requires continuous CPU computation.

If we have 2 logical CPUs:

With GOMAXPROCS=1, only one goroutine can execute Go code at a time.
With GOMAXPROCS=2, two goroutines can execute Go code simultaneously.

Therefore, the second configuration can complete the calculation faster because it utilizes both available CPUs.

However, increasing GOMAXPROCS beyond the available CPU capacity does not provide additional physical processing power.

Case 2: I/O-intensive tasks

Suppose our backend server is handling multiple requests, and some requests require:

Fetching data from a database.
Reading files from disk.
Calling external APIs.
Waiting for network responses.

During these operations, a goroutine may become blocked or suspended while waiting for the result.

Instead of keeping the CPU idle, Go can schedule another runnable goroutine.

This allows the application to continue processing other requests while some operations are waiting.

This is one of the major reasons backend applications use many goroutines even when they have relatively few CPU cores.

6. Why can excessive threads introduce overhead?

Suppose we have 2 logical CPUs but many runnable OS threads.

The operating system must schedule those threads onto the available CPUs.

When switching between threads, the operating system may need to:

Save the execution state of the currently running thread.
Restore the execution state of another thread.
Update scheduling information.
Handle CPU cache effects and other scheduling costs.

This is called context switching.

Context switching is not the same as moving a thread to disk or physically removing it from memory. Threads generally remain represented in memory while they are waiting to execute.

If the system performs excessive scheduling and context switching, it can introduce overhead and reduce performance.

However, more threads do not automatically mean more overhead. The impact depends on how many threads are runnable, what they are doing, and how the workload is structured.

7. Why does Go use more OS threads when the system has limited CPU cores?

Go's runtime manages goroutines and OS threads separately.

For CPU-intensive workloads, Go generally uses its available parallel execution capacity efficiently.

For I/O-intensive workloads, some goroutines may wait for operations to complete.

Go can schedule other runnable goroutines while those operations are waiting.

For certain blocking system calls, an OS thread may become blocked, and the Go runtime can arrange for other goroutines to continue executing using other available threads.

For network I/O, Go commonly uses runtime network polling to avoid requiring one blocked OS thread for every waiting network connection.

This helps Go handle a large number of concurrent requests without requiring an equivalent number of OS threads.

8. Practical Experiment: Measuring CPU Parallelism in Go

We created a Go program to calculate prime numbers within a specified range using multiple goroutines.

The program used:

2 available logical CPUs.
4 goroutines.
Different GOMAXPROCS configurations.
Execution time as the performance measurement.

Experiment results

GOMAXPROCS	Workers	Primes found	Execution time
1	4	78,498	388.075 ms
2	4	78,498	205.7652 ms
3	4	78,498	244.6589 ms
4	4	78,498	272.6667 ms

What did we observe?

When GOMAXPROCS = 1:

Only one goroutine could execute Go code at a time.

Execution time: approximately 388 ms.

When GOMAXPROCS = 2:

Two goroutines could execute Go code simultaneously across the available CPUs.

Execution time: approximately 206 ms.

The workload completed substantially faster.

When GOMAXPROCS = 3 or 4:

The configuration permitted more parallel execution capacity, but our machine still had only 2 available logical CPUs.

The measured execution time increased compared with the 2-CPU configuration.

This may involve scheduling overhead and measurement variability. Additional parallelism does not guarantee improved performance.

We should repeat the benchmark multiple times and compare averages before drawing a firm conclusion.

Conclusion from the experiment

More CPU cores can improve the performance of CPU-intensive workloads when the application can utilize them effectively.

However, more threads, goroutines, or parallel execution slots do not automatically make an application faster.

We must identify the workload, available hardware resources, and potential bottlenecks.

CODE:

package main

import (
"flag"
"fmt"
"runtime"
"sync"
"time"
)

func isPrime(n int) bool {
if n < 2 {
return false
}

for i := 2; i*i <= n; i++ {
    if n%i == 0 {
        return false
    }
}
return true

}

func main() {
procs := flag.Int("procs", 1, "Number of CPUs to use")
flag.Parse()

runtime.GOMAXPROCS(*procs)

const limit = 1000000
const workers = 4

var wg sync.WaitGroup
var total int64

var mu sync.Mutex

start := time.Now()

chunk := limit / workers

for w := 0; w < workers; w++ {
    wg.Add(1)

    go func(worker int) {
        defer wg.Done()

        count := 0
        startNum := worker*chunk + 2
        endNum := (worker + 1) * chunk + 1

        for n := startNum; n <= endNum; n++ {
            if isPrime(n) {
                count++
            }
        }

        mu.Lock()
        total += int64(count)
        mu.Unlock()
    }(w)
}

wg.Wait()

elapsed := time.Since(start)

fmt.Println("Available CPUs:", runtime.NumCPU())
fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))
fmt.Println("Workers:", workers)
fmt.Println("Primes found:", total)
fmt.Println("Execution time:", elapsed)

}

OUTPUT :

D:\Scaling>go run main.go -procs=1
Available CPUs: 2
GOMAXPROCS: 1
Workers: 4
Primes found: 78498
Execution time: 388.075ms

D:\Scaling>go run main.go -procs=2
Available CPUs: 2
GOMAXPROCS: 2
Workers: 4
Primes found: 78498
Execution time: 205.7652ms

D:\Scaling>go run main.go -procs=3
Available CPUs: 2
GOMAXPROCS: 3
Workers: 4
Primes found: 78498
Execution time: 244.6589ms

D:\Scaling>go run main.go -procs=4
Available CPUs: 2
GOMAXPROCS: 4
Workers: 4
Primes found: 78498
Execution time: 272.6667ms