Performance Testing: Measuring a 40 Percent Query Speed-Up
Verifying the gain from a CQRS split with before-and-after measurements.
Mert Celal Yılmaz · Full Stack Developer · Updated:
A hundred records and a filter screen runs fine; push that to ten thousand and the same screen can slow to a crawl. Performance testing exists to measure exactly that gap, not whether the code returns the right answer, but how long it takes and how much it costs to get there. You run the same queries against data volumes close to real usage and measure time, query count, memory.
The first version of an apartment management system ran reads and writes through the same model. After splitting them with CQRS, reading through queries shaped around what the read side actually needs rather than the write side, the measured improvement in query performance came out to 40 percent.
That number didn't come from a gut feeling, it came from testing the before and after against the same dataset and the same scenarios. Being able to say '40 percent faster' instead of 'it feels snappier now' matters both for checking your own work and for explaining it to the rest of the team. Optimizing without measuring first is usually just guessing, so I measure first.
Most of that 40% didn't come from CQRS as a pattern on its own, it came from what the split let us do on the read side specifically — queries switched to AsNoTracking, so EF Core stops allocating change-tracking memory for rows that were only ever going to be displayed, and the filtering queries got trimmed to project just the columns the list view needed instead of pulling full entities. Cutting both the tracked memory overhead and the amount of data shipped back accounts for most of the measured gain.
Splitting read and write models doesn't buy performance by itself — CQRS just gives you a seam where the two sides can be optimized independently, and the gain depends entirely on what you do with that seam. Data volume matters just as much: costs that stay invisible against a few hundred rows locally only show up at a realistic volume. That was also the deciding factor when I designed the filtering and access layer for more than 10,000 documents on a cloud-based document management system I built solo.