This is probably known to a lot of people. But I think it’s worth repeating.
I was running some OLTP tests against a pretty powerful server. And everything appeared to be right on the client driver side and on the server side. But I was getting rather miserable throughput numbers. For this class of servers and for this type of OLTP workloads, I’d expect the transaction throughput per second (tps) to be well over 5000 tps. Instead, I was getting about 800 tps.
No matter how hard I tried to drive the workload against the server, the throughput just refused to budge. And the server resource consumption didn’t change much either as I increased the number of users going against the server.
In addition, for a given load level, when the average response time was expected to be in the 3ms range, the actual average response time was about 4~5ms. Not exactly what was expected, but not five or six times worse off either. However, upon a closer examination of individual transaction response times, I found that sometimes a transaction would take longer than 200ms to complete, and occasionally a transaction might even take well over 1000ms to complete. These long-running transactions (relatively speaking anyway) were what killed the overall transaction throughput.
In the end, it was discovered that the root of the problem was a mismatched duplex setting on the server. While the network card on the client driver machine was set to full duplex, the network card on the server was set to half duplex. After a simple change of the duplex setting on the server to full duplex, the transaction throughput for the exactly same workloads went up from 800 tps to more than 5000 tps.
Now in the real world, you may not see such a dramatic impact because you may not be consistently running small transactions at an extremely high frequency. For instance, if you are running large reporting queries, you may not feel any difference at all.