>One location I maintain an application is about to go virtual. So, instead of having one big box with 32 GB of RAM and 4 CPU, accessing SQL Server directly from another server on the same network, the new setup will involve a virtual environment with at least two IIS servers and one SQL Server, still on another server. The difference is all IIS servers will only have 4 GB of RAM and less powerful CPUs. Add to that that the access to the SQL Server will have to go through a firewall. To my perception, the response time from the ASP.NET application will suffer from a degradation. Anyone can confirm that or add some input? Presently, we process at 12 hits a second at 0.1 to 0.2 second average. I doubt I would be able to obtain those numbers when switching to the new environment. One thing for sure, just the fact that the IIS server will have to go through a firewall to access to SQL Server will add a level securiy but this cannot be as fast as what we have actually where the IIS server and the SQL Server resides on the same class C.

It sounds like the SQL server is remaining the same, so you don't have to worry about its raw performance - just potentially more overhead in accessing it (?)

I suggest doing some monitoring of your existing IIS server and environment, before it is switched to virtual e.g.

- average RAM and CPU utilization
- average network bandwidth utilization
- disk subsystem performance e.g. average disk queue length

Then, you will have some solid figures and will be able to tell the client that to achieve X hits/sec with Y milliseconds response, I need Z CPU/RAM/disk/network

The obvious dangers with virtualizing are not provisioning enough CPU and RAM. The results of your monitoring, and knowing the relative performance of current vs. new CPUs/cores can let you provision appropriately.

Less obvious are potential bottlenecks with network and disk. A single gigabit link can be plenty for a single server but if several virtual servers are sharing it, that may not be enough. Also, the disk subsystem can get hammered if too many VMs are running on it.

Slowdown in accessing the SQL server depends on how you're going to do it. Assuming everything is still local ( LAN, not WAN ), if they open a firewall port for you it might slow you down by only a few milliseconds. If you go in through something like a VPN it might be a little slower, and it could take some extra CPU at your end to support the VPN.

Every environment is different - so monitor & test first.