Blog.
Updates, releases, and insights
from the RantAI team.
12+ articles
Cargo: The Build System That Makes Everything Else Feel Broken
Discover how Cargo—Rust's all-in-one build system and package manager—eliminates build configuration headaches and makes development fast and reproducible.
Raffy Aulia Adnan
Read article
rustc: The Compiler Behind Every Rust Program You've Ever Run
Explore the four-stage rustc pipeline—parsing, safety analysis, LLVM optimization, and code generation—that makes Rust memory-safe and blazing fast.
Raffy Aulia Adnan
Read article
The Best of Both Worlds: Combining Tokio and Rayon for Maximum Efficiency
Learn how to safely combine Tokio and Rayon in Rust using `spawn_blocking` to balance async I/O and parallel CPU workloads without thread starvation.
Raffy Aulia Adnan
Read article
Performance and Debugging: Tuning Async Rust for Production
Performance and Debugging Async Rust: Finding the Bottleneck When Everything Is Non-Blocking (And Nothing Makes Sense Anymore) Debugging async code is a special kind of experience. In synchronous code, you set a breakpoint, step through line by line, and watch values change. The execution path is linear, predictable, and traceable. In async code, your "function" is actually a state machine that gets polled by a runtime scheduler across multiple threads, interleaved with thousands of other tasks, and the stack trace shows you the runtime's internal scheduling loop instead of your actual code. It's like trying to follow a conversation at a cocktail party by reading the room's acoustics. The good news: Rust's async ecosystem has developed excellent tools for debugging and profiling async code. The bad news: you need to know they exist, because println! debugging—everyone's guilty pleasure—is particularly unhelpful when tasks interleave their output unpredictably. At RantAI, we've invested heavily in async observability—structured logging, Tokio's tracing integration, and runtime metrics that tell us exactly where our async pipelines spend their time. This article, drawn from Chapter 6, Section 6.8 of our guide "The Rust Programming Language," covers the practical techniques for debugging and optimizing async Rust code. The #1 Problem: Accidentally Blocking the Runtime The most common async performance bug is synchronous work on an async thread: // BAD: This blocks a Tokio worker thread #[tokio::main] async fn main() { let result = tokio::spawn(async { std::thread::sleep(std::time::Duration::from_secs(5)); // BLOCKS! // Other tasks on this thread are starved for 5 seconds 42 }).await.unwrap(); } // GOOD: Use tokio::time::sleep (yields the thread) #[tokio::main] async fn main() { let result = tokio::spawn(async { tokio::time::sleep(tokio::time::Duration::from_secs(5)).await; // Yields! 42 }).await.unwrap(); } Common blocking culprits: std::thread::sleep (use tokio::time::sleep), std::fs operations (use tokio::fs), std::sync::Mutex (use tokio::sync::Mutex or spawn_blocking), CPU-heavy computation (use spawn_blocking + Rayon), and synchronous HTTP clients (use reqwest with async). Detecting Blocking with Tokio Console # Cargo.toml [dependencies] console-subscriber = "0.2" tokio = { version = "1", features = ["full", "tracing"] } #[tokio::main] async fn main() { console_subscriber::init(); // Enable Tokio Console // ... your async code } Tokio Console (tokio-console) is a diagnostic tool that shows you real-time task states: which tasks are running, which are idle, which are blocked, and how long each poll takes. A task that polls for too long is blocking the runtime—and Tokio Console makes it immediately visible. Structured Logging with tracing use tracing::{info, warn, instrument}; #[instrument] // Automatically logs function entry/exit with arguments async fn process_request(user_id: u64, action: &str) -> Result<(), String> { info!("Processing request"); let data = fetch_data(user_id).await.map_err(|e| { warn!("Failed to fetch data for user {}: {}", user_id, e); e })?; info!(data_size = data.len(), "Data fetched successfully"); Ok(()) } async fn fetch_data(user_id: u64) -> Result<Vec<u8>, String> { tokio::time::sleep(tokio::time::Duration::from_millis(50)).await; Ok(vec![1, 2, 3]) } #[tokio::main] async fn main() { tracing_subscriber::fmt::init(); // Initialize logging process_request(42, "login").await.unwrap(); } The tracing crate is the standard for async Rust observability. Unlike log, it's designed for structured, contextual logging that tracks data across async task boundaries. #[instrument] automatically creates spans with function arguments, so you can trace a request through your entire async pipeline. Performance Profiling: Where Is Time Spent? Measuring Task Duration use std::time::Instant; use tracing::info; async fn timed_operation(name: &str) { let start = Instant::now(); // ... async work tokio::time::sleep(tokio::time::Duration::from_millis(100)).await; let elapsed = start.elapsed(); info!( operation = name, duration_ms = elapsed.as_millis(), "Operation completed" ); } Identifying Slow Polls If a single poll of your future takes more than ~10-100 microseconds, you might be doing too much work between yield points. Solutions: break up computation with tokio::task::yield_now().await, move CPU-heavy work to spawn_blocking, or restructure to have more granular .await points. Common Async Performance Patterns Buffer sizes matter. Channels (mpsc, broadcast) with too-small buffers cause back-pressure. Too-large buffers waste memory. Profile to find the right size. Connection pooling. Creating a new database connection per request is slow. Use connection pools (sqlx::Pool, deadpool) that reuse connections across tasks. Batch operations. Instead of 1000 individual database inserts (1000 round trips), batch them into groups (10 round trips of 100 each). The async overhead per operation matters at scale. Limit concurrency. Spawning 100,000 tasks that all hit the same database will overwhelm it. Use tokio::sync::Semaphore to limit concurrent operations to what the downstream system can handle. use tokio::sync::Semaphore; use std::sync::Arc; async fn process_with_limit(items: Vec<String>, max_concurrent: usize) { let semaphore = Arc::new(Semaphore::new(max_concurrent)); let mut handles = vec![]; for item in items { let permit = semaphore.clone().acquire_owned().await.unwrap(); handles.push(tokio::spawn(async move { process_item(&item).await; drop(permit); // Release semaphore slot })); } for handle in handles { handle.await.unwrap(); } } async fn process_item(item: &str) { tokio::time::sleep(tokio::time::Duration::from_millis(50)).await; } Broader Implications: Observability as Architecture At RantAI, async observability isn't an afterthought—it's part of the architecture. Every async pipeline stage has structured tracing with timing. Every external call has timeout wrapping. Every concurrent operation has concurrency limits via semaphores. The result is systems where performance issues are diagnosed in minutes, not days—because the data is already there in the traces. Practical Applications & Strategic Takeaways For newcomers: Install tracing and tracing-subscriber on day one. Use #[instrument] on your async functions. When something is slow, the traces will tell you where. For production teams: Add Tokio Console for development debugging. Add tracing with structured output (JSON) for production observability. Add concurrency limits (Semaphore) to protect downstream systems. For performance engineers: Profile poll durations. If any poll takes more than 100μs, you're blocking the runtime. Move that work to spawn_blocking or add yield points. Our Commitment to Open Knowledge RantAI is committed to open education. Async performance and debugging are covered in Chapter 6, Section 6.8 of our guide, "The Rust Programming Language," freely available online. Explore these concepts further: https://trpl.rantai.dev Support Our Mission & Get Your Handbook Get the Handbook on Amazon KDP: https://www.amazon.com/dp/B0DHCMD3F2 Get the Handbook on Google Play Books: https://play.google.com/store/books/details?id=INwfEQAAQBAJ What's the trickiest async bug you've debugged? How did you find it? Share your debugging war stories! #RustLang #AsyncDebugging #Tokio #Tracing #Performance #RantAI #LearnRust #Observability #Profiling #SystemsProgramming
Raffy Aulia Adnan
Read article
Error Handling in Async Rust: Making Failures Graceful in Non-Blocking Code
Master async error handling in Rust! Learn how ? works with .await, handle task joins, add timeouts, build retries, and choose anyhow vs thiserror.
Raffy Aulia Adnan
Read article
The Async Decision Framework: When to Use async, Threads, Rayon, or All Three
Stop rewriting your Rust code! Use Tokio for I/O, Rayon for CPU, and channels for communication. Learn the ultimate Rust concurrency framework.
Raffy Aulia Adnan
Read article
Tokio Concurrency: Spawning Tasks and Running the World in Parallel
Discover how Tokio concurrency scales Rust apps from Chapter 6 of RantAI's guide. Master tasks, channels, and async mutexes to handle thousands of requests!
Raffy Aulia Adnan
Read article
Concurrency Is Not Parallelism: Why Tokio Isn't Enough and Rayon Fills the Gap
Master Rust concurrency vs parallelism: use Tokio for I/O-bound tasks and Rayon for CPU-bound workloads to optimize your system architecture.
Raffy Aulia Adnan
Read article
Introduction to Tokio: The Runtime That Makes Async Rust Practical
Discover Tokio, the production-ready async runtime for Rust that powers thousands of concurrent connections using an efficient multi-threaded event loop.
Raffy Aulia Adnan
Read article
Understanding Futures: The Lazy Computation Model That Powers Rust's Async
In Rust, calling an async function creates a lazy Future that does nothing until .await-ed. Discover how zero-cost state machines power async.
Raffy Aulia Adnan
Read article
Async Programming in Rust: Why Non-Blocking Code Is the Future of Performance
Discover why Rust's async model outperforms traditional threads, using zero-cost futures and Tokio to handle 10k+ concurrent requests efficiently.
Raffy Aulia Adnan
Read article
async/await with the Standard Library: Building Non-Blocking Code from First Principles
Rust async/await starts with Future, poll, Pin, and Waker. Learn these primitives first, then Tokio’s runtime and scheduling become easier to understand.
Raffy Aulia Adnan
Read article