2

We have a Windows Server 2012 R2 web server running IIS 8.5 hosting a number of ASP.NET applications each in their own app pool. The server was originally specced to cope with expected load, but since then the client has also insisted on installing McAfee antivirus. We've excluded the application directories from the on-demand scanning mechanism.

We're finding that when the applications start up for the first time we're seeing particularly high (too high) CPU load. The two processes that are hogging the CPU are alternately Visual C# Command Line Compiler (csc.exe) and McAfee On-Access Scanner Service (mcshield.exe).

I would expect csc.exe to be pretty high on CPU during initial compilation of a restarting ASP.NET application, but I'm concerned that McAfee is interfering and making this process take longer and hurt the CPU more. Has anyone had similar experience?

If so, are there any other specific directories that I should be excluding from the scan? Or is it more correct to be recommending against antivirus on web servers?

If not, then is there anything I can do to prevent such a load on CPU during application startup?

Tom Troughton
  • 143
  • 5

1 Answers1

1

Based on your description, I'd recommend excluding directories where there are any DLL used by the application. This includes the GAC and/or Microsoft.NET\Framework|Framework64\ folders. Ensure neither application DLLs nor csc.exe are scanned. Then check if the performance gets better.

milope
  • 441
  • 2
  • 5
  • Thank you, I've requested changes along the lines of your suggeston so will report back. – Tom Troughton Sep 26 '16 at 21:41
  • @getsetcode worked? – Bilgin Kılıç Feb 08 '19 at 13:08
  • 1
    @BilginKılıç Results were inconclusive. Unfortunately the anti-virus policy had to be changed by a third party and although we requested this specific change we didn't see improvements. However, we were unable to confirm whether this was because the advice didn't work, or whether the change was incorrect. In the end, significant changes were made to the application which meant far less load placed on the server during startup so this problem went away. – Tom Troughton Feb 08 '19 at 14:05