Skip to content

Commit ff1f70c

Browse files
committed
Adds blog post about RedisWorker.
1 parent 22f4a3b commit ff1f70c

File tree

1 file changed

+98
-0
lines changed

1 file changed

+98
-0
lines changed
Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
---
2+
date: 2026-01-13T00:00:00Z
3+
title: RedisWorker Delivers 2.3x Performance Improvement
4+
authors:
5+
- dkliban
6+
tags:
7+
- performance
8+
- tasking
9+
- redis
10+
---
11+
# RedisWorker Delivers 2.3x Performance Improvement
12+
13+
This performance breakthrough came from an innovative collaboration with AI. We explained the PostgreSQL load challenges we were facing to an AI assistant, which designed an algorithm that offloads resource locking to Redis while maintaining task ordering guarantees. The AI then helped write the implementation code and test suite, dramatically accelerating our development process. This approach allowed us to rapidly prototype and validate the solution, demonstrating how AI can be a powerful tool for tackling complex architectural challenges.
14+
15+
We're excited to share results from our recent performance benchmarking that demonstrate significant throughput improvements in Pulp's tasking system. By offloading resource locking from PostgreSQL to Redis and eliminating the task unblocking mechanism, we've achieved more than double the task processing throughput.
16+
17+
<!-- more -->
18+
19+
## Benchmark Results
20+
21+
Our testing compared the traditional `PulpcoreWorker` implementation against the new `RedisWorker` implementation under identical conditions:
22+
23+
**PulpcoreWorker Performance:**
24+
25+
- Processed: 20,296 completed tasks
26+
- Time window: 671.25 seconds
27+
- **Average throughput: 30.24 tasks/sec**
28+
29+
**RedisWorker Performance:**
30+
31+
- Processed: 21,419 completed tasks
32+
- Time window: 306.91 seconds
33+
- **Average throughput: 69.79 tasks/sec**
34+
35+
The RedisWorker achieved **2.3x higher throughput** (69.79 vs 30.24 tasks/sec) while processing a similar number of tasks in less than half the time.
36+
37+
## How We Achieved This
38+
39+
The performance improvement comes from two key innovations: offloading resource lock coordination to Redis and eliminating the task unblocking mechanism. Here's what changed:
40+
41+
**Traditional PulpcoreWorker Approach:**
42+
43+
- Uses PostgreSQL advisory locks for task resource coordination
44+
- At any given time, one worker constantly queries the database to find and unblock waiting tasks
45+
- This unblocking process runs continuously, creating steady database load
46+
- Lock operations create additional load on the PostgreSQL database
47+
- Suitable for most deployments, especially when Redis isn't available
48+
49+
**New RedisWorker Approach:**
50+
51+
- Uses Redis distributed locks for resource coordination
52+
- No unblocking mechanism needed - workers simply attempt to acquire locks for waiting tasks
53+
- If locks can't be acquired, the task remains in the queue for the next worker to try
54+
- Eliminates the continuous database queries for task unblocking
55+
- Significantly reduces both database load and unnecessary CPU work
56+
- Scales better under high task volumes by doing less work overall
57+
58+
## Architecture Benefits
59+
60+
By separating resource locking from the main database:
61+
62+
1. **Reduced PostgreSQL Load**: Database queries are limited to task CRUD operations, not constant lock checking
63+
2. **Faster Lock Operations**: Redis's in-memory operations are significantly faster than database queries
64+
3. **Better Scalability**: Workers can check and acquire locks with minimal overhead
65+
4. **Improved Throughput**: The system can process more than twice as many tasks per second
66+
67+
## Configuration
68+
69+
The worker type is configurable via the `WORKER_TYPE` setting:
70+
71+
```python
72+
# Use PostgreSQL advisory locks (default, stable)
73+
WORKER_TYPE = "pulpcore"
74+
75+
# Use Redis distributed locks (higher performance)
76+
WORKER_TYPE = "redis"
77+
```
78+
79+
## Important Considerations
80+
81+
While RedisWorker delivers superior performance, there are some trade-offs to consider:
82+
83+
- **Redis Dependency**: Requires a Redis instance to be available
84+
- **Stability**: PulpcoreWorker remains the default and is the more mature implementation
85+
86+
## When to Use RedisWorker
87+
88+
RedisWorker is ideal for:
89+
90+
- High-volume task processing environments
91+
- Deployments where Redis is already part of the infrastructure
92+
- Scenarios where task throughput is critical
93+
94+
## Looking Forward
95+
96+
These performance improvements represent a significant step forward for Pulp's scalability. We're continuing to enhance the RedisWorker implementation and explore additional optimizations.
97+
98+
The RedisWorker implementation will be available soon in upcoming Pulp releases. We encourage users with high-throughput requirements to evaluate it in their environments once released.

0 commit comments

Comments
 (0)