Dat:
Any time you run a single TCP stream and add any latency to the system, you should expect a difference in throughput.
For example, if the server sends 8 packets before waiting for an acknowledgment and your increase the latency, your throughput will drop, as the number of times per second the server can send 8 packets will drop.
Instead of calling this "performance" or "speed", which can mean a lot of things, I prefer to call this "single connection throughput".
It's very hard to measure single connection throughput in a repeatable fashion, and get the same result in the real world.
In a performance lab you can get latency down to a bare minimum, but I just measured the ping time to 3 floors away through a multitude of high-end switches at 1100 uS, versus a box same rack at 153 uS. Most traffic management devices aren't going to add that much latency to your packets. So your physical infrastructure in the real world will overwhelm any effects you might see in a performance lab when you add a traffic management device to the system.
What kind of single connection throughput you get depends on the TCP stack implementations (window scaling enabled?), latency, and network congestion.
As hoolio suggested, you could try switching to the wan-optimized TCP profile on the BIG-IP and see if that helps. Or you can cut latency through the BIG-IP by using the PVA ASIC, which has low 10s of microseconds of latency.
So why does single-connection throughput matter for this application?
Paul