15,000 statements at about 2.5 round trips each. 0.49 ms per round trip on the short path, 1.30 ms on the real one. Same query plans, same database.
The DBA runs the report. Queries are fast, there are no bad plans and no waits. The application still takes tens of seconds for a routine save.
Each team looks at its own layer and correctly finds nothing wrong. The ticket bounces between them.
One routine save issued around 15,000 SQL statements, and with a commit per statement each one cost about two and a half network round trips.
On the short path the round trip was 0.49 ms. On the path the application actually used it was 1.30 ms. Multiply it out: about 18 seconds of pure network wait on the short path, about 49 seconds on the real one, for a single save. No index, CPU or memory upgrade changes that number.
Commit per business operation, not per statement, and replace row-at-a-time loops with set-based SQL in the chattiest code paths.
Put the application and the database on the lowest-latency path and measure the round trip with a probe rather than trusting the data centre diagram. A 15,000-statement save is a defect, not a tuning problem: raise it with the vendor and get it fixed at source. Before relocating a database, capture a production hour and replay it against the target, so the move lands with evidence.
49 sfor one routine save, on a database with a clean report
What the logs said
connect logs 14,920 statements per save, commit per statement app→db rtt 1.31 ms on the actual path (0.49 ms available) predicted wait ≈ 49 s per save observed 51 s verdict failure mode TWO: latency × chattiness, not the plans fix commit per operation, shorten the wire, raise the code path with the vendor