Slow troughput virtual kemp VLM-200 on Hyper-V 2012R2

0

Hi 

My Lab environment consists of a Supermicro Server with the mainboard X10SLM-F.
There is installed a virtual free Kemp Loadmaster (VLM-200) and some virtual MS Server 2012 R2 Webservers.

When I download a file from a webserver, which is a Kemp virtual service, the troughput will never be more than 200 KB/s.
When I download the file direct from the Webserver, there is a troughput grater than 40MB/s.

The virtual Kemp and the webservers use the same physical network interface.

I cannot find any helpful information into the log files.

Any ideas?

 

 

17 comments

Avatar
0
steven

I have the same issue. I use an on-premise cloud-drive solution. If i go through the perimiter-firewall and then directly to the device, I can download as fast as the internet connections allow (wirespeed which is 100Mbit).

When I put the Free LM inline (2-armed, one IF towards firewall, one IF in backend-subnet where the device is), the speed drops to 300 to 400 kBps which is way slower than the 20Mbit (around 2500 kBps) the free VLM should be capable of. The speed is consistent in both scenarios.

(I tried one-armed at first, then went for a 2-armed setup to not traverse the firewall twice but it makes no difference).

Can anyone shed some light on this? We are not going to buy a real license if a Kemp LM cannot even deliver the licensed throughput (20Mbit in case of a free LM).

Avatar
0
Mark Deegan

Hello,

You might try SSL offloading without re-encrypt on the VIP. it should have maximum transfer speed then

best regards

Mark

Avatar
0
steven

Hello Mark,

Thanks for your reply.

I use a VIP that serves as a "https  catch-all" and it has 4 RS behind it. If I disable re-encrypt, they all go "offline". If I disable SSL accell. completely for that VIP, they come online again but nothing is reachable (maybe a NAT thing).

I actually played around with several scenario's incl. SSL accell. but in my config, I must use SSL with enc. and re-enc. in order to make the 4 RS "go online" and reachable from the internet. I use L7 and Transparency is not enabled on the VIP.

If I look at the CPU load of the VM, both from inside the WUI as well as in VMware, the CPU load is 3% max. The ESXi servers have AES-NI exposed to the VM's so the SSL stuff gets offloaded to HW anyway. Why would "not re-encrypting" give such a performanceboost?

Avatar
0
Mark Deegan

Hi Steven,

You will need to have your real servers available on port 80 unencrypted as the LM will be responsible for the SSL connection on the front end and go unencrypted to the back end. Then when you enable SSL offload with out re encrypt the servers will be online. this is because the config will be as follows

Client to VIP on 443 SSL connection, LM to Real server on 80 (No SSL), Real server to LM on port 80, LM VIP to client on 443 with SSL. 

So the front end will have SSL but the back end will be unencrypted.

regards

Mark

Avatar
0
steven

Hi Mark,

I configured it according to your suggestion. I see port 80 hitting the device and not 443 anymore. But the speed is exactly the same :-(

The server hardware is not a slouch. The physical CPU are fast (multi-core 3.4 Ghz), the LM Appliance has 2 vCPU's and AES-NI is exposed to the vLM. The vLM's CPU is absolutely picking it's nose (2 to 3%). It feels "throttled/capped"  (well it is ofcourse but should be capped at 20 Mbit).
The hardware should be more than capable of decrypting en re-encrypting without breaking a sweat.

I'm running the current vLM release by the way.

Avatar
0
steven

I'm baffled. I did a download over the local network now, so no Internet, and the performance is exactly the same: around 200 KB/s throughput, CPU picking it's nose.

I really have the feeling that the developer, who wrote the code to throttle the Free LM, entered 2 Mbit instead of 20 Mbit as the capping-value.

Avatar
0
steven

Hello,

Are there any developments in this area? Any news?

 

Kind regards,
Steven

Avatar
0
gregor.kistler

I´ve exactly the same issue.

I´m running a couple of services (some directly without web servers, some additional behind a couple of Nginx) behind a two-arm Free LM version 7.2.37.1.14531.RELEASE-VMware.

Upload bandwidth is maxing out 1Gb/s but non of my services is able to deliver download speeds higher than 400KB/s while using SSL termination at the LM.

Using a non-SSL setup and balance only HTTP traffic the download speed gets nearly doubled but not more than 1000KB/s which is still 1000 times slower than what my LAN connection is capable of.

Connecting directly to any of the services gives me full download bandwidth.

MTU size (1500 or 9000) doesn´t make any difference so does the speed link (set it from automatically - which is 10000Mb/s, Full Duplex in my home lab - down to 1000baseT/Full).

 

Avatar
0
gregor.kistler

Same can be seen with the latest version 7.2.38.0.14750.RELEASE which I´ve just upgraded.

Avatar
0
steven

So do I. No change in the latest release.

By now I think it's fair to say that KEMP's claim that the Free edition is throttled to 20Mbit is not correct. It's more like 3 to 3.5 Mbit in reality (which makes it practically unusable to be honest).

Avatar
0
gregor.kistler

To be honest I´ve missed the point about bandwidth limitations at all when I´ve decided to use this product.

To get decent bandwidth I would need to spend at least $2.5k or actually more like $5k (set up a trial of the VLM-5000 a couple of seconds ago and it does what I was looking for) which won´t happen - way too much for a home lab. 

I will switch back to HAproxy and keepalived solution.

Avatar
0
steven

It's okay to throttle down the free version of a commercial product (for obvious reasons) but it would be best if one is simply honest about what people can expect. If the documentations says the free version has an artificially capped throughput of 20Mbit, than it should be 20Mbit and not 3-isch Mbit.

I'm not assuming any intentional wrong-doing. On the contrary. But I would appreciate a comment from KEMP on this stating the indented positioning of the free version of the LM product.

If the 3-ish Mbit throughput that everybody is seeing, is the consequence of a coding-error, then a fix to bring it to the (promised) 20Mbit would be the proper thing to do.

Avatar
0
michel.zehnder

I recently learned that there is a bug in recent firmwares which might make it slow. It should be resolved in 7.2.39:

 

------------------------

I can see you have listed your firmware version as 7.2.38. There is a known bug on this firmware version which has a negative impact on throughput speeds, especially the download speeds for http/https services etc.

This bug has been picked up by our developers and will be fixed in our next upcoming firmware version, 7.2.39 which is due for release in early August. If you are looking for a quicker fix, some users have reported that downgrading to firmware version 7.1.35.3, which is our long term stable (LTS) version, has help fix the download speeds issue. If you decide this approach, please take a look at the release notes for 7.1.35.3 before doing so and be aware that a password reset may be required in order to access the WUI again after the downgrade!



Avatar
0
n.fehlauer

Hi Michael,

we encounterd the same problem with extremly slow performance for Exchange 2016 layer-7 https access. Downgrade to 7.1.35.3 fixed the issue for us. Hopefully the new 7.2.39 will fix this and the hyper-v problem.

 

Regards

Norbert

Avatar
0
Marcus Lindner

Hello,

any news about this bug?

I Have Version 7.2.36.2.14271

 

Regards

Marcus

Avatar
0
n.fehlauer

This was fixed in the mentioned 7.2.39 Version or later.

Avatar
0
Marcus Lindner

OK thx for info.

Now i must found a upgrade howto for the free edition :)