Async-Redis

 view release on metacpan or  search on metacpan

examples/slow-redis/README.md  view on Meta::CPAN

# Slow Redis Example

Demonstrates non-blocking I/O by intentionally delaying each request by 1 second.

## The Point

With **blocking I/O**, a single-threaded server handling 5 requests that each take 1 second would need 5 seconds total (sequential processing).

With **non-blocking I/O**, those same 5 concurrent requests complete in ~1 second because they all sleep concurrently while the event loop handles them.

## Running

```bash
# Start Redis
docker run -d -p 6379:6379 redis

# Start the server
REDIS_HOST=localhost pagi-server --app examples/slow-redis/app.pl --port 5001
```

## Testing

### Single request (~1 second)
```bash
curl http://localhost:5001/
```

### 5 concurrent requests (should be ~1 second, not 5!)
```bash
time (for i in 1 2 3 4 5; do curl -s http://localhost:5001/ & done; wait)
```

### 10 concurrent requests
```bash
time (for i in $(seq 1 10); do curl -s http://localhost:5001/ & done; wait)
```

### Compare with fast endpoint (no delay)
```bash
curl http://localhost:5001/fast
```

## Expected Output

```
Slow Redis Response
===================
Worker PID:     12345
Redis Time:     1704307200.123456
Request took:   1.002s (including 1s sleep)

This request intentionally waits 1 second to demonstrate non-blocking I/O.
Run multiple concurrent requests - they should all complete in ~1 second total!
```

## How It Works

1. Request arrives
2. `Future::IO->sleep(1)` yields control to the event loop
3. Event loop can accept and process other requests during the sleep
4. After 1 second, all sleeping requests wake up
5. Each request gets Redis TIME and responds

The key is that `Future::IO->sleep()` is **non-blocking** - it doesn't block the thread, it just schedules a callback for later while the event loop continues processing other work.



( run in 0.761 second using v1.01-cache-2.11-cpan-524268b4103 )