This content has been marked as final. Show 2 replies
On metalink i found some notes about this issure
SmartView communicates over HTTP using .NET. This just means that requests and responses are sent in a standard XML format that is tucked in the HTTP headers. The mechanism is the same as when your internet browser requests a file or submits a form (simplification). A standard Microsoft component that is part of Internet Explorer is used for this.
There are three components (four if you include the network) in a SmartView refresh:
-the web server
-the HFM application server
It is easiest to troubleshoot when they are on separate machines. (Running SmartView on the server to see whether it works better is a useful test to see what effect the network is having, but doesn't show any other bottlenecks.) If you run Task Manager on these 3 machines showing the Performance tab, you will see initial activity on the client as Excel clears the cells and the request is converted into XML. Then you see the web server get busy as it receives and parses the request. Then the application server is busy as it send the data, then the web server is busy as it compiles the results into XML again, and finally the client parses the XML, pushes the data into cells and runs an Excel calculation. This last stage is the longest of all. Overall, it is typical to see the client doing 90-95% of the work, so client performance is a very important factor. Look out for Excel's memory usage increasing and RAM becoming in short supply. Often, user dissatisfaction with refresh times can be alleviated by giving them more RAM or a faster PC.
The situation we are dealing with here, however, is when the chain of events described above is interrupted. In this case, you will see the client or the web server wait in vain for a response from the next machine in the chain. The case of invalid XML is similar, but the response is truncated so that the XML is not well-formed when it arrives. XML consists of matching pairs of tags and is not well-formed when a closing tag is missing. This can be caused by certain network settings such as packet size (see later). The end result in either case is the same: as Excel cleared the cells before sending the request, cells are left blank or with zeroes.
Your job now is to work out why the particular component is failing.
Check the HTTP time out in the registry:
The time-out limit is five minutes for versions 4.0 and 4.01 and is 60 minutes for versions 5.x and 6. Also, the time-out limit is 30 seconds for Windows Internet Explorer 7. To change the settings, add the above keys. The above values are hexadecimal, not decimal and correspond to 18000 milliseconds (3 minutes) and 240 minutes for the receive time-out. See
Once you make those changes, my recommendation is that you reboot the client machine.
Look for errors in logs showing that the web app didn't respond/disconnected or timed out waiting for another application (i.e. the HFM application server). Eliminate load balancers etc. during testing in order to isolate the problem and to ensure that the user always goes to the same web server otherwise, logs can be hard to interpret. See also the IIS Tuning Guide for IIS settings. We cannot recommend particular settings, as each client must establish the optimal settings for their own environment after performance testing. If necessary, engage the services of a suitably qualified consultant.
HFM application server performance is very dependent on whether the data is already in RAM or not. One symptom, where the first refresh fails but the second one succeeds, is probably a sign that the cache needed to be populated and once that had been done (by the first refresh) it went faster. HFM loads whole subcubes (Scenario, Year, Value and Entity) into cache, so asking for lots of accounts in the same subcube is fast, but asking for lots of entities will inevitably slow things down as it runs out of RAM and starts unloading subcubes to make room for more. The HFM event log (HsvEventLog.log) shows this happening, but don't forget that the messages you see are a normal consequence of the way HFM works and are not a problem unless you see a hugely elevated number of them during the period the refresh occurs. Another sign would be page file thrashing.
If there are several servers in a cluster, use sticky sessions in HFM to make sure tests always go the same server, or hit one server directly rather than using the cluster.
Solutions here involve giving more RAM to the server (probably not possible because of the 2 GB limit) and changing the worksheet design to restrict the number of subcubes accessed. A separate consolidation server, so that reads are not competing with intensive consolidations and calculations, would be a good thing.
To find out if packets get fragmented, use
ping -l size -f
to send a big packet with the 'don't fragment' flag. E.g.
Ping -l 1024 -f oracle.com
If you see a reply like Reply from 126.96.36.199: bytes=1024 time=200ms TTL=245 then the size you specified is below the packet limit of the network. But if you use, for example, 2000 in place of 1024, you get Packet needs to be fragmented but DF set, then you know you have exceeded the limit. Combine this investigation with a Fiddler trace (https://www.fiddler2.com/fiddler2/) to see what size data messages are being sent and received.
If you seriously want to go into this in more detail, then it will take a considerable effort on your and your IT Department's part. My general advice would be:
1. During this process, fix your environment so that it is predictable. Register a single HFM application server and connect to that. Use a single web server and don't go through Apache or any other redirector. Make sure we know which machine to go to for logs. This would be a temporary measure and it doesn't stop the other users using the full, load balanced system so long as it doesn't involve your server.
2. As far as possible keep other users from using it during testing, unless you are specifically testing for performance under load. We want to see what activity is due to SmartView and not random other jobs.
3. Use PerfMon on all three machines: client, web server and application server.
4. Clear Logs before testing and note the times of each test so the logs can be correlated.
5. Log CPU activity, memory usage, network throughput, page faults, thread count etc. I'm no expert on this so get advice from someone who is.
6. In addition to the performance logs, from the IIS Server get:
* HTTP.SYS Error Log - %windir%\System32\LogFiles\HTTPERR (Default location; configurable)
* IIS Website Log - %windir%\System32\LogFiles\W3SVC# (Default location; configurable)
* Event Log (both System and Application) in EVT and TXT (tab separated) formats
7. From HFM Application server get:
* HsvEventLog.log (in <HFM install>\Server working Folder)
* Event Log (both System and Application) in EVT and TXT (tab separated) formats
8. Be aware of all timeout settings in your environment (i.e. IIS & the network) and time your tests. This can show whether it is an ASP timeout, script timeout, client side timeout or whatever. Note that the Web Session Timeout setting for SmartView in HFM's Server and Web Configuration is a separate issue from IIS timeouts. Web Session Timeout controls the length of idle time before SmartView makes the user log in again. Default 20 mins.
9. Run Fiddler traces to directly observe the XML and check for HTTP failures.
- Tuning IIS 6.0 for HFM
- SmartView Performance FAQ
Both are available from Support.
Author: Andrew Rowland
Version: 11.x (Fri, 30 October 2009)"
Thanks for your info. We still encountered performance issue when more than 20 users using SmartView to open web form built for Hyperion Planning. We have servers with 8 CPU core but the loading generated from SmartView is much much higher than normal web form via Workspace.
Any specific configuration parameters/setting can be tuned? We have already limited the no. of data to be retrieve by SmartView but seems no help.