|
| 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