Video summary

Implementing Redis' PING Command | Redis Internals

Main summary

Key takeaways

Technology

Main goal of the video

Build a minimal Redis command server by implementing Redis’s simplest command: PING, matching how the real Redis server behaves and returns RESP-encoded replies.

How PING behaves in normal Redis (baseline checks)

The video demonstrates three client behaviors using the standard redis-cli against Redis on port 6379:

  1. PING (no arguments) → +PONG\r\n as a Simple String (no quotes).
  2. PING hello → $5\r\nhello\r\n as a Bulk String (shown with quotes in the CLI output).
  3. PING hello world → error: “wrong number of arguments for ping command” (too many arguments).

Codebase / commit referenced

  • Implementation repo: github.com/dicedb/dice
  • The speaker instructs checking out the third commit, where ping support is implemented.

Implementation details (server architecture)

1. Command representation: Redis CMD

In sync_tcp.go (server entry handling TCP streams), the code introduces a structured object called Redis CMD to represent:

  • the root command (e.g., PING)
  • the arguments (e.g., hello, etc.)

This acts as a “drop-in replacement” style structure: command + N arguments.

2. Decoding client input into []string

Instead of treating input as raw bytes, the server:

  • reads the incoming stream
  • uses a RESP-related decoder (in RESP)
  • converts the decoded token list into a typed array of strings ([]string) rather than generic interfaces

Assumption: Redis clients send commands as an array of strings, e.g.:

  • PUT key value → ["PUT", "key", "value"]
  • PING hello → ["PING", "hello"]

3. Converting tokens into a Redis CMD

In the read path:

  • tokens[0] becomes the root command (uppercased)
  • tokens[1:] becomes the argument list

4. Response handling: respond(connection, CMD)

The server runs an infinite loop:

  • reads a command
  • calls respond

respond is the core dispatcher:

  • evaluates the command
  • writes the appropriate RESP reply back to the TCP connection

If evaluation errors occur, it uses RESP error encoding:

  • errors are sent as -ERR_MESSAGE\r\n (minus sign prefix + message + CRLF)

Evaluation logic: eval and respond, specifically evalPing

The evaluation layer maps the root command (PING) to evalPing (for now, everything routes to it in this tutorial).

evalPing checks argument count and returns:

  1. More than 1 argument → error: wrong number of arguments for ping command

  2. 0 arguments → PONG (Simple String reply)

  3. 1 argument → that argument (Bulk String reply)

RESP encoding: encode(value, simpleString?)

The code adds an encoder counterpart to the earlier decoder.

Current encoder is string-only, tailored to PING:

  • Simple String
    • +{string}\r\n
  • Bulk String
    • $<length>\r\n{string}\r\n

The video emphasizes the difference:

  • PING → Simple String (PONG)
  • PING <arg> → Bulk String (hello)

Functional verification (drop-in replacement behavior)

The server is run on port 7379 (Dice server). Using redis-cli, it reproduces normal Redis behavior:

  • PING → pong (no quotes)
  • PING hello → hello with quotes (bulk string)
  • PING hello world → same “wrong number of arguments” error

Claim: for PING, this implementation is a drop-in replacement for Redis.

Benchmarking / performance comparison

To compare speed, the video uses Redis’s redis-benchmark locally:

  • command: ping_mbulk
  • 10,000 iterations
  • 1 concurrent connection (concurrency not yet implemented)

Requests per second (rps):

  • Normal Redis on 6379: ~10,810.81 rps (one cited run)
  • Dice server on 7379: ~11,695 rps (another run ~11,547 rps)

A later repeat showed variance where Redis sometimes led (~12,224 rps vs ~11,547 rps), attributed to CPU scheduling and local machine conditions.

Key point: performance is described as comparable and sometimes faster in microbenchmarks, but it does not claim Dice beats real Redis overall (real Redis is far more complex and optimized).

Next planned improvement (from the speaker)

Current server implementation is not concurrent.

With multiple clients (e.g., -c 2), one connection can block another and may hang.

Next direction:

  • implement concurrency via IO multiplexing / event loop
  • keep it single-threaded (event-loop techniques, not multithreading)

Main speakers / sources

  • Speaker: video narrator/instructor teaching “Redis Internals”
  • Source code: github.com/dicedb/dice (third commit referenced)
  • Standards/tooling referenced: Redis RESP behavior, redis-cli, redis-benchmark

Original video