TL;DR: The async model is a contract. In .NET, async methods are expected to do little CPU work, spend most of their time awaiting input/output, and make long-running CPU work explicit. Lease renewal depends on that contract. If a handler hides blocking or CPU-heavy work inside an async method, the scheduler assumptions behind renewal can fall apart. The message pump depends on the broker API, but it also depends on the runtime’s execution model. After publishing the previous article...
TL;DR: A visibility timeout is a lease. It tries to keep two consumers from working on the same queue message at the same time, but only for a limited period. If message handling takes longer than that period, the pump must renew the lease while business code continues to run. That sounds like a small addition until renewal needs scheduling, cancellation, shutdown behavior, mutable pop receipts, delete coordination, and a policy for what to do when renewal fails. The first version of the...
TL;DR: Once a benchmark shows a win, put the optimized code back into the profiling harness. Compare the before and after memory and CPU profiles to see whether the larger execution path benefits too. A good benchmark table feels great. The before number is slower, the after number is faster, allocations drop, and the ratio looks impressive. After hours of staring at profiler stacks and benchmark output, that table feels like the finish line. Unfortunately, the table only describes the isolated...
TL;DR: Reading bytes from a queue is the easy part of a message pump. Things get difficult when message handling writes to a database, sends more messages, fails halfway through, moves to another broker, or runs in a cloud service with different transaction semantics. A small infrastructure project can quietly turn into a platform commitment. None of this looked particularly scary when we started. It looked like a loop: read from a queue, deserialize a message, find the handler, and call it. We...
TL;DR: Useful benchmarks are controlled experiments. Copy the relevant production code, trim away unrelated work, choose realistic parameters, measure one responsibility, and use short runs for direction before spending time on full runs. Most benchmark examples look cleaner than the code we work with. Suspiciously cleaner. They compare string concatenation with StringBuilder. They call a static method. They pass one value in and return one value out. Those examples are useful for learning...
TL;DR: A queue can remove temporal coupling between a front end and a back end, but something still has to read the messages and run the business code behind them. That something is the message pump. Processing one message at a time protects downstream systems but increases queue wait time. Fire-and-forget processing looks faster until concurrency runs away. In practice, the pump needs an explicit limit. The medical invoicing system already worked. That made the request harder, not easier. It...
TL;DR: Profilers show cost, not priority. Start with memory, then CPU, use filters to zoom into the code path you own, and let domain context decide which hot spots deserve a benchmark. The first profile is usually disappointing. You attach the profiler, run the profiling harness, take a snapshot, and get a giant list of allocations, call stacks, framework methods, runtime methods, transport code, serializer code, and your own code hiding somewhere in the middle. The tool did its job. It showed...
TL;DR: Before writing a benchmark, build a small profiling harness that makes the code path visible. Run it in Release mode, keep unrelated work out, add clear profiler snapshot points, and collect both memory and CPU evidence. Production code is a terrible place to start a performance investigation. There is too much happening at once. Production code is not bad; it is alive. It has real configuration and input/output, plus logging, retries, dependency injection, serialization, network calls...
TL;DR: A benchmark can tell you whether code got faster. It cannot tell you whether the code mattered. For that, use a loop: profile with a profiling harness, improve a hot path, benchmark and compare, profile again, then ship and observe production. The first benchmark I wrote looked deceptively easy. I needed a class, a few attributes, and a method. Then I could run BenchmarkDotNet and get a table. It looked a lot like unit testing, which made me dangerously confident. That confidence did not...
TL;DR: Micro-optimizations are not a substitute for design work. They are how you earn the right to redesign. In the Azure Service Bus SDK, repeated work in the Body property first led to smaller allocation fixes. Once those fixes exposed the shape of the problem, a small internal redesign made the code faster, clearer, and easier to reason about. “This code is bad. We should rewrite it.” Most developers have heard that sentence. Many have said it. I have too. The problem is not...