Forum Discussion
Slow application performance when using BIG-IP LTM VE for load balancing.
- Feb 19, 2016
The overall answer to this question is, yes there is a limitation... but it depends on the license type purchased. The license I had available to me had a 10 Mbps limitation on it, rendering it useless for load testing scenarios. This information in the assorted comment threads.
The following references on F5 were helpful, but ultimately, I would have liked to find a SOL that explicitly calls out this limitation, as it feels somewhat masked (it may not be, when talking to account teams from F5, but unfortunately I came into this post-purchase.) It is not listed in the licensing information when running tmsh show /sys license.
- https://devcentral.f5.com/questions/limited-bandwidth-on-virtual-edition
- https://devcentral.f5.com/questions/f5-big-ve-lab-license
- https://devcentral.f5.com/questions/bigip-ltm-ve-lab-limitations
Thank you again to WLB for all of the help. It was WLB's guidance that helped me find the answer to this question. I am just posting the direct answer so that the thread can be closed.
Thanks for the extensive feedback. VE should be able to handle such a load with ease.
This command may provide some insight;
more /var/log/tmm | grep UNIC
My v11.4.1 VE (Openstack on KVM on RHEL) returns this;
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC: set MTU for eth1 to 9000
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC: eth1 supports tx csum
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC: eth1 supports TSO
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC [un1] unic_attach(450): Hardware checksum offload is enabled
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC [un1] unic_attach(462): TCP segmentation offload is enabled
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC [un1] unic_attach(466): VLAN hardware checksum is disabled
<13> Dec 3 11:54:18 host-192-xxx-xxx-xxx notice UNIC [un1] unic_attach(470): VLAN TCP segmentation offload is disabled
I'm not sure what the last two lines might indicate and unfortunately can't test under load. Would be interesting to see what you get back on v11.3.
I think, until you get to v11.5 at least the only next logical step is to do a packet capture client and server side and try to identify where the delay actually is.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com