Ah, but it's an average wait time. And, even 3 ms can be slow if you doing lots and lots of them.
It's possible the network is "slow", but in my experience, often the underlying problem is the developers are going to and from the "well" much more often then they really need to.
Laugh, many years ago, I interviewed for a DBA position at the Federal Reserve in DC. One interview question was, what can you do to improve SQL performance. I answered, teach your SQL developers how to optimize SQL performance.
Anyway, as an example, you might want to read this BLOG posting. Toward the end, the result of "tuning" how SQL was being used was: "This was significant performance improvement. From 1 hour 22 mins to 2 mins 55 secs !"
Understand, cannot say what the root of your problem is, and your network may indeed be the bottleneck, or a contributor to slow performance, but even when the network is the problem, unless the network is really, really (really) bad, improving it, even to the best possible, doesn't often make a huge difference.
Oh, BTW, network latency can be a real performance reducer, but is some cases, the "best" is still bad. For example, clients accessing servers on the other side of the world (literally) have much distance based latency, but we cannot make electrical or optical signals travel faster (and more bandwidth doesn't help).
The keys to fast SQL performance, don't transmit data across the network if you don't really need to, but if you do need to, don't do it in many partial operations.
(BTW, an example of the impact of partial data transfers, every use tftp across a WAN vs. a LAN? See the WAN be much slower, and not even coming near using all available bandwidth? An example of not sending data if you don't need to, ever compress data to reduce transmission time?)
