cancel
Showing results for 
Search instead for 
Did you mean: 
slayer977
Level 7

Performance Tuning Tips for LabEnvironment

Jump to solution

Hi,

I have a WebGateway running in my lab to test some configs, compatibility issues and so on...

There are less than 10 systems (win2008 server, win7, ipad, iphone, ...) using the web gateway as proxy.

But they are not using the web gateway each day intensiv.

As stated above, it´s just a lab...

To me it seems, that each first attempt to reach a website takes some time. As if the web gateway is coming back from standby.

(I am not using an proxy authentication.)

So, what I am looking for is for some tuning tips, to make the web gateway as fast as possible for this small environment.

What could/should I check or change?

My Web Gateway is running as a virtual appliance on esxi5.

The esxi server has a i5 2400m cpu, 8gb ddr-3 ram and two SATA HDDs.

I sized the virtual appliance as followed:

Is this sufficient?

CPU:

- 1 virutal socket

- 1 vitual core per socket

RAM: 1024MB

HDD: 20GB (thin provisioned)

In ESX config:

What can I change to make the Web Gateway faster?

- should I change cpu settings?

- should I give more ram?

- should I change hdd from thin to thick?

In Web Gateway config:

- should I disable caching?

- should I do someting with DNS?

Best Regards,

-slaYer977-

0 Kudos
1 Solution

Accepted Solutions
eelsasser
Level 15

Re: Performance Tuning Tips for LabEnvironment

Jump to solution

The guest resources you have allocated are very small. They are even below the supported minimum.

2 CPUs (Either 2 Sockets or 1-Socket/2 Cores)

RAM: absolute bare minimum is 2Gig. Highly recommend 4Gig.

HDD: 80Gig minimum for lab. (Support requires minimum of 200Gig for any machine in production)

Disable Caching: One of the biggest bottlenecks in VM is Disk/IO. With caching turned on, a LOT of disk I/O occurs.

Thin provisioning is fine if caching is disabled.

If not, pre-allocate disk.

DNS: hard to say. If you are NOT doing authentication, you can point to an ISP DNS servers. If you are doing authentication, it should be an AD DNS server and not an ISP DNS.

As long as the latency to it is minimal in either case, you should be ok.

I run my lab with with these settings and it's ok for 4-5 clients:

Capture.jpg

0 Kudos
3 Replies
eelsasser
Level 15

Re: Performance Tuning Tips for LabEnvironment

Jump to solution

The guest resources you have allocated are very small. They are even below the supported minimum.

2 CPUs (Either 2 Sockets or 1-Socket/2 Cores)

RAM: absolute bare minimum is 2Gig. Highly recommend 4Gig.

HDD: 80Gig minimum for lab. (Support requires minimum of 200Gig for any machine in production)

Disable Caching: One of the biggest bottlenecks in VM is Disk/IO. With caching turned on, a LOT of disk I/O occurs.

Thin provisioning is fine if caching is disabled.

If not, pre-allocate disk.

DNS: hard to say. If you are NOT doing authentication, you can point to an ISP DNS servers. If you are doing authentication, it should be an AD DNS server and not an ISP DNS.

As long as the latency to it is minimal in either case, you should be ok.

I run my lab with with these settings and it's ok for 4-5 clients:

Capture.jpg

0 Kudos
slayer977
Level 7

Re: Performance Tuning Tips for LabEnvironment

Jump to solution

HI eelsasser,

thank you very much for your answer.

I will copy your settings.

best regards,

-slaYer977-

0 Kudos
jspanitz
Level 7

Re: Performance Tuning Tips for LabEnvironment

Jump to solution

eelsasser,

I was just about to post a similar question.  Our lab is running on ESXi 5.  The guest is 2 CPUs, 8GB ram and 50GB disk.  Web cache is turned off.

The issue for us is on file downloads.  The downlaod seems ok, but the AV scan is tremendously slow.  So slow that something seems wrong and I'm actually a bit afraid to roll MWG7 out into production.

On a scan, both CPUs hit 50% and stay there for a good 400 seconds when downloading this test file -

http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/M....

We've tried other size files with the similar results.  All take way to long to scan.

0 Kudos