VMware Cloud Community
rafal
Contributor
Contributor
Jump to solution

vCOPs http gzip compression

Hello,

because vCOPs is generating a lot of http(s) traffic, we want to enable gzip compression to save bandwidth.

On appliance there are running tomcat and apache2 daemons. I guess apache2 is proxy for tomcat.

Question is: what's best practice to enable gzip compression in vCOPs env? Should it be enabled on tomcat or apache?

Reply
0 Kudos
1 Solution

Accepted Solutions
mark_j
Virtuoso
Virtuoso
Jump to solution

It is not best practice to enable gzip compression if it is disabled OOTB. Doing so would be unsupported. They're running Linux + tomcat, etc, but they should be treated like proprietary appliances and managed/administered within our supported guidelines.

You said that there is a lot of http traffic. Is that client traffic, or adapter collection to vCenter + other sources?

Are your users using vSphere UI or Custom dashboards? The HTTP traffic shouldn't be so much as to cause a problem and I've actually never heard of it as a complaint. It is feasible that you're using Custom dashboards that have short interval refresh times, which  would cause some higher HTTP traffic due to content refresh, but that would be a far lesser problem compared to higher load being placed on UI/Analytics VMs..

If you find this or any other answer useful please mark the answer as correct or helpful.

View solution in original post

Reply
0 Kudos
4 Replies
mark_j
Virtuoso
Virtuoso
Jump to solution

It is not best practice to enable gzip compression if it is disabled OOTB. Doing so would be unsupported. They're running Linux + tomcat, etc, but they should be treated like proprietary appliances and managed/administered within our supported guidelines.

You said that there is a lot of http traffic. Is that client traffic, or adapter collection to vCenter + other sources?

Are your users using vSphere UI or Custom dashboards? The HTTP traffic shouldn't be so much as to cause a problem and I've actually never heard of it as a complaint. It is feasible that you're using Custom dashboards that have short interval refresh times, which  would cause some higher HTTP traffic due to content refresh, but that would be a far lesser problem compared to higher load being placed on UI/Analytics VMs..

If you find this or any other answer useful please mark the answer as correct or helpful.
Reply
0 Kudos
rafal
Contributor
Contributor
Jump to solution

Hello Mark,

thanks for reply.

We'r monitoring entire link (only 30Mb) accross WAN. We spoted that workstation (located in LAN1) which is conn. to vCOPs (located in LAN2) is generating majority of traffic (8Mb stream).

We have overall 7 dashboards. Dash which is consuming most bandwitch is "Health Status" tab, with selected "Folder" as resource kind. In 15 selected folders we have about 85 VM to monitor. Widget Refresh Interval is set to 60 sec. We'll try to increase refresh value (up to 180 sec.).

Reply
0 Kudos
mark_j
Virtuoso
Virtuoso
Jump to solution

Clients really shouldn't be sucking up an inordinate amount of bandwidth.. and even when they do have heavy dashboards open it's defin not in steady streams. I'd suggest bumping refresh up to 5min intervals, as that's how often data refreshes anyway from vCenter.

The widgets that suck up alot of bandwidth are those with analysis periods, such as highly-populated charts and the like. Also, Top-N when you've got large periods configured.. these can really gobble up resources on the UI.

How did you narrow things down to the health status widget specifically?

If you find this or any other answer useful please mark the answer as correct or helpful.
Reply
0 Kudos
rafal
Contributor
Contributor
Jump to solution

We ran quick net tests. I think you'r right - refresh interval short value seems to be main culprit here.

After all, still it would be nice to have http gzip compression enabled Smiley Happy - I believe it's no hard to implement.

Reply
0 Kudos