MaxScale Multiplexing and Caching – Part 2

Part 2 – Understanding MaxScale Thread Architecture

This multi-part series breaks down each section into easy logical steps.

Part 1 – Complete Guide for High-Concurrency Workloads

Part 2 – Understanding MaxScale Thread Architecture

Part 3 – Backend Sizing and Connection Pooling

Part 4 – Tuning MaxScale for Real Workloads

Part 5 – MaxScale Multiplexing

Part 6 – MaxScale Caching

Part 7 – Warnings & Caveats

Part 8 – Key Takeaways

---

MaxScale is multi-threaded. Each worker thread handles a subset of client connections, with no shared state, reducing lock contention.

General Rule for Thread Allocation

MaxScale is a multi-threaded proxy, where each worker thread handles a subset of client connections. Proper thread allocation is crucial for maximizing throughput, minimizing latency, and ensuring predictable performance.

Rule of Thumb:

MaxScale threads ≈ number of CPU cores

Explanation:

• Each MaxScale thread runs independently, processing multiple sessions.
• Aligning threads to CPU cores reduces context switching and allows better CPU cache utilization.
• Over-provisioning threads can lead to CPU contention and increased latency.

Examples:

• 4-core VM → 4 threads: Suitable for small to medium workloads.
• 8-core VM → 8 threads: Handles higher concurrency, balancing multiple client sessions per thread.
• 16-core server → 16 threads: Supports very high concurrent workloads, often used for enterprise-scale events or spikes.

Additional Considerations:

• For workloads with highly variable session activity, monitor CPU and thread usage; minor adjustments (+/- 1 thread) may optimize performance.
• Thread pinning (CPU affinity) can further improve predictability by binding threads to specific cores (see CPU Pinning section).

Scaling for Concurrency

MaxScale distributes client connections across its worker threads. Understanding how concurrency maps to threads is essential for tuning performance and avoiding bottlenecks.

Formula:

Average concurrency per thread = total expected client connections / number of MaxScale threads

Example Calculation:

• Expected total connections: 2,000
• MaxScale threads: 8
• Average load per thread: 2,000 ÷ 8 = 250 active sessions per thread

Explanation:

• Each thread will handle multiple concurrent client sessions, so the processing capacity of each thread should be sufficient for the expected load.
• If the number of connections per thread is too high, you may experience queuing or increased latency.
• Conversely, over-provisioning threads for low concurrency can waste CPU resources.

Practical Tip:

• Monitor thread statistics and session latency during testing to ensure each thread operates within optimal load limits.
• Adjust the number of threads and backend connection pools iteratively to match real-world workload patterns.

---

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Page 8