Note: the above applies equally to Discoverer Viewer and Oracle Portal and probably many other Oracle tools
What appears to be happening is that McAfee is checking the data being returned from Discoverer before allowing it to be displayed on the screen. If you have McAfee and are using either IE6 or IE7 you may be complaining to your IT department about the slow running of Discoverer. This is not a Discoverer issue. We can prove this by running the same report in Firefox where it will run fast.
If you are observant, you can tell that something is amiss because the browser itself will indicate that it has finished processing (the green status bar at the bottom right will be removed or the Windows icon at the top right will stop wiggling around), yet the output still does not display and may not do so for 10 or more seconds.
As a background to all of this, IE uses a Windows component called Windows Scripting Host, or WSH for short, to execute JavaScript (and other things). My version of WSH was 5.6. The most recent version is 5.7, though Microsoft claim that there are no major changes in 5.7! However, one of the changes that they do mention is an improvement to JavaScript that should benefit pages with lots of AJAX-like features (like our Discoverer and Portal pages).
Here is the link to download WSH 5.7:
http://www.microsoft.com/downloads/details.aspx?FamilyID=47809025-D896-482E-A0D6-524E7E844D81&displaylang=en
I installed WSH 5.7, and while this did help IE7 it had no impact on IE6. We therefore seem to have the the following four options:
- Do not use McAfee - probably not an option for many users if the corporate policy is to use McAfee
- Disable the ScriptScan feature of McAfee across the enterprise - there may well be some resistance to this from your IT department
- Do not use IE6 but use Firefox
- Upgrade to IE7 and upgrade to WSH 5.7
I guess there is a fifth option which would be to get McAfee to include an option whereby you could specifiy which domains you trust data to come from and therefore bypass the scanning process.
Options 1, 3 and 4 are relatively simple to do although not simple to apply enterprise wide. I will therefore now concentrate on option 2 and show you how to disable the ScriptScan feature inside McAfee.
- First of all, right-click on the McAfee icon in the taskbar. You will see the following pop-up
- From the pop-up, select On-Access Scan Properties. The following dialog box will be displayed.
- Click on the ScriptScan tab
- Uncheck the box called Enable ScriptScan
- Click the Apply or OK buttons
I found that disabling ScriptScan usually takes effect immediately and you can even stay within the browser. You should see an immediate improvement in Discoverer performance.
When I tried re-enabling ScriptScan, to prove that McAfee was indeed the culprit, we noticed that we had to close the browser, and therefore the Discoverer session, before scanning was implemented again.
I found another interesting article on Andy Dominey's Blog concering this issue. You may want to take a look (link)
Note: as previously mentioned, the above applies equally to Discoverer Viewer and Oracle Portal and probably many other Oracle tools
If you have a solution for this or know of another workaround please let me know (email)
3 comments:
I'm afraid the WSH upgrade may be giving you a false positive resolution, and is therefore not a viable option.
From what I can gather, McAfee replaces WSH with it's ScriptProxy (see: http://support.microsoft.com/default.aspx?scid=kb;en-us;891605); this is what causes the slowdowns.
When you upgrade WSH, you likely replace the ScriptProxy with proper WSH and therefore actually STOP the scanning from occurring at all.
- Davey
Could you be more precise when you wrote about "serious degradation in performance"? Any time measurement?
Also, what do you mean by "this did help" when you wrote "I installed WSH 5.7, and while this did help IE7 it had no impact on IE6? Again, any time measurement?
Having tested WSH 5.7 on MSIE6 and MSIE7 with McAfee 8 / ScriptScan engine running, I did not see improvements: performance is the same under MSIE 6 and MSIE 7. This may confirm Davey Shafik's argument about false positive.
In our application, ScriptScan impact is about 5 ms per script expression
Post a Comment