Hi All,
I have a dashboard that have total 37 Panel (in 13 rows) and each panel is displaying results from 2 searches. Kind of like this
Row 1 Panel1 Panel2 Panel3
--Search1 --Search1 --Search1
--Search2 --Search2 --Search2
Row 2 Panel1 Panel2 Panel3
--Search1 --Search1 --Search1
--Search2 --Search2 --Search2
The dashboard is slow(well there are 74 searches) , but it loads fine in Firefox. When I open the same dashboard in IE, it first gives me this prompt:
Stop running this script?
A script on this page is causing your web browser to run slowly.
If it continues to run, your computer might become
unresponsive.
It works fine if I reduced the no of panel to 28( from 37). Has anyone faced similar issue or any suggestions on troubleshooting this?
Note: All panels are showing data in Table (from Sideview).
IE8 timeout value by default is 5,000,000 statements. This timeout value can be increased by using a Registry Editor such as Regedt32.exe, open this key:
• HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Styles
• Note If the Styles key is not present create a new key that is called Styles
• Create a new DWORD value called "MaxScriptStatements" under this key, and set the value to the desired number of script statements. I doubled the value to 10,000,000 (Decimal) or 989680 (Hexadecimal).
Restart IE 8
Oh! This is where it gets a little perverse... Depending on a lot of characteristics of the base results and of the various postprocess searches, it may actually be faster to break them up again into some small number of searches. On the other hand it may not. It all depends on the search results - # of fields and # of rows, and the nature of the postprocess searches. If you can email me the whole shebang and let me know approximate row numbers involved, I can comment at that level.
Ohh I forgot to mention that. I am using one base search and there are 75 post process(In addition to 3 more searches for dropdown population). This dashboard is for some sort of validation based on whole event, so summary index option is ruled out here.
Well IE is quite a bit slower but also it's possible that when the dispatch requests are all forced to queue (74 searches is too many!!!!) IE may interpret it as a client-side hang.
Is it feasible to lower the number of searches being dispatched? With that many you can almost certainly combine sets of N searches into little postprocess datacubes, especially if you see places where you are getting the same raw data off disk more than once. Can you also schedule any of them or summary index any of them?