This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Endpoint Security and Visual Studio

Hi, 

We run Sophos Endpoint Secuirty on our desktop machines and a few of those machines have Visual Studio on them. When we was in the process of setting Sophos up, we imported a list of file types (extensions relating to Visual Studio) that we wanted to excluce from being scanned and they have been specified in both the 'on-access scanning' and Windows exclusions areas of the Enterprise Console. 

However, my collaegues are reporting that when compiling a program in Visual Studio, it is taking a considerable time for the project to compile and they have noted that the CPU % utililisation is higher than before Sophos was placed on to the machine. 

Do you have any specific recommendations to make regarding what changes can be made to stop Sophos causing the issues stated above?

:45447


This thread was automatically locked due to age.
Parents
  • Hello Aarongu,

    what is both the 'on-access scanning' and Windows exclusions areas?

    Did you already use some other AV before (as you didn't mention this)? Naturally scanning is not "free" so you can expect some overhead, I wouldn't unconditionally call this an issue though. If CPU% is higher then there have been idle cycles before and higher isn't necessarily a sign of contention.

    Indisputably compile time will increase when scanning is done, the question is how it compares to before and what quantity considerable is. I never refrain from mentioning that the users' attitude to AV plays an important part and biases perception. I had more than one case where exclusions were an absolute necessity at first. Last was some client/server application where the developers claimed that scanning (especially on the server) was causing the abysmal performance. In cooperation with the project manager we added some exclusions - on both server and clients - and all was well. Subsequently we quietly removed them, first from the clients and then also from the server, and (not so) surprisingly didn't hear any complaints. I should add that the developers also made some changes - but only for feature improvements and not to, perish the thought!, amend some unlucky design decisions (which didn't go too well with scanning) we had pointed out. Just an aside ...

    Application development is a special case and might to some extent be impacted. Where did you get the list of exclusions from - which apparently doesn't have the desired effect? Did you approach this systematically or just start off with the exclusions? I'd compare performance with and without the exclusions (please note that usually only infectable files are scanned and only once per session - if they haven't changed they are not rescanned but just verified). I'd also assess the performance with on-access completely turned off. You won't get the same performance as without scanning - measuring the actual impact of the various settings and scenarios might help mitigating the effect though.

    Christian

    :45465
Reply
  • Hello Aarongu,

    what is both the 'on-access scanning' and Windows exclusions areas?

    Did you already use some other AV before (as you didn't mention this)? Naturally scanning is not "free" so you can expect some overhead, I wouldn't unconditionally call this an issue though. If CPU% is higher then there have been idle cycles before and higher isn't necessarily a sign of contention.

    Indisputably compile time will increase when scanning is done, the question is how it compares to before and what quantity considerable is. I never refrain from mentioning that the users' attitude to AV plays an important part and biases perception. I had more than one case where exclusions were an absolute necessity at first. Last was some client/server application where the developers claimed that scanning (especially on the server) was causing the abysmal performance. In cooperation with the project manager we added some exclusions - on both server and clients - and all was well. Subsequently we quietly removed them, first from the clients and then also from the server, and (not so) surprisingly didn't hear any complaints. I should add that the developers also made some changes - but only for feature improvements and not to, perish the thought!, amend some unlucky design decisions (which didn't go too well with scanning) we had pointed out. Just an aside ...

    Application development is a special case and might to some extent be impacted. Where did you get the list of exclusions from - which apparently doesn't have the desired effect? Did you approach this systematically or just start off with the exclusions? I'd compare performance with and without the exclusions (please note that usually only infectable files are scanned and only once per session - if they haven't changed they are not rescanned but just verified). I'd also assess the performance with on-access completely turned off. You won't get the same performance as without scanning - measuring the actual impact of the various settings and scenarios might help mitigating the effect though.

    Christian

    :45465
Children
No Data