Billing Export Performance Rebuild

At Pacific Data Resources I worked on an enterprise billing system whose Excel export sat directly in a daily workflow. Fifteen seconds does not sound like an outage, and that is exactly why this kind of latency survives for years: it is under the threshold where anyone files a ticket, and over the threshold where the person waiting stops what they were doing. Run often enough by enough people, it is a real tax on the working day.

The cost was never the work itself — it was how many times the system crossed a boundary to do it. The pipeline handled rows one at a time, and every row made its own trip from the client, through the backend, into a stored procedure and back. Each of those trips pays a fixed toll regardless of how little it carries: a network hop each way, command setup, and a separate procedure invocation. When the per-row work is as small as it was here, that fixed toll is not part of the runtime — it is essentially all of it, and the total scales with the number of rows rather than the amount of data.

The restructure inverted the shape. Instead of the backend calling the database once per row, it gathers the full set and hands it over in a single call, and the stored procedure processes all of it in one pass. Thousands of round trips become one. Just as importantly, the database is then doing what it is actually built for — one set-based operation under a single execution plan, rather than the same plan re-invoked a few thousand times over one row each. The two orders of magnitude come from removing the round trips, not from making any individual step faster; nothing in the per-row logic needed to get quicker.

The system was ASP.NET Core and WCF services over SQL Server and Oracle, and this turned out to be one instance of a pattern rather than a one-off. The query tuning, indexing, and stored-procedure work that cut execution time by 40% elsewhere in the same system was the same instinct applied in different places: stop asking the database for things one at a time, and let it answer in sets.

• Cut a core billing Excel export from 15 seconds to 0.135 seconds — a 99.1% reduction.
• Traced the latency to row-by-row processing: each row made its own round trip from client through backend to stored procedure, so runtime scaled with row count rather than data volume.
• Restructured the pipeline to gather the full row set and pass it to the stored procedure in a single call, processed as one set-based operation.
• Collapsed thousands of database round trips into one, removing the per-call fixed cost that accounted for nearly all of the original runtime.
• Worked across ASP.NET Core and WCF services backed by SQL Server and Oracle.
• Paired the export work with query and stored-procedure tuning that reduced execution time by 40% elsewhere in the system.
• Targeted latency that sat below the reporting threshold but inside a daily workflow — the kind that never becomes a ticket.