BO Sizing and Configuration 1

[klyon]

I'm just starting a BO project and am looking for general guidelines for a small installation. I'm planning at a 2 server solution for 20 thin/thick report developers and 60 WebI users. Also have BCA and Developer to install.

I'm looking for guidance on server sizing and configuration (how to split up the apps).

Any thoughts would be appreciated!

TIA for you help,

-Kris

 

[Maiden]

Hi Kris
For Web Deployments consider the following:
· The number of documents
· The user activity
· The distribution of components
· Intranet verses Extranet

It is highly recommended that all servers used in the Business Objects system be dedicated to the server application it is running. This means no databases or other applications should be installed on the server machines.

Sizing Webi Installation
As a general guide if a company is going to have 20 users at any point there will be 10% of these users logging in. Each BOBJ.exe requires 50Mb of RAM, thus 20*50 = 1000Mb of memory!

1 Processor can run four Busobj.exe processes. To optimise this if you only have one processor go to the BO manager and set the minimum number of busy process to 4. This means that a 4 processes will run automatically!

If you set the maximum number of busy processes to 5 the maximum number of processes which will run are 5, any more processes which try to run will be killed!

If one goes to Bomanager and sets the number of loaded processes to 5. 5 processes will automatically be running waiting for the client to refresh a report.

Therefore if 10 reports are run on a webi server which has one processor, 4 will be processed concurrently and 5 will be waiting in the que to be processed and one will fail.

How to optimize performance through load balancing
Here is some advice about how to distribute your BusinessObjects processes:
1. As a general rule, you should keep the HTTP server and HSAL on the same machine as the Dispatcher. This will speed up the transmission of requests to the appropriate BusinessObjects processes.
2. As start pages, and document and universe access pages are generated by the Page Generator and sent to the client through the HTTP interface, it is also advisable to keep the Page Generator on the same machine as the HTTP server and HSAL.
3. Because they are so processing-intensive, the obvious candidates for distribution to additional cluster nodes are the BusinessObjects Manager modules, of which several can exist, in a single cluster. Free to function on machines hosting few other processes, these modules can work more efficiently, and with a reduced risk of failure. If one BusinessObjects Manager does fail, the system automatically and seamlessly redirects requests for the repository and corporate databases to another BusinessObjects Manager module on another machine within the same cluster.
4. Set the Load Node Factor for each server with care, according to each machine’s capacities. This kind of fine-tuning can make an enormous difference in the overall performance of your system.


Cluster Manager
The focus should be on the cluster manager since it will be in control the entire server system. The cluster manager has to handle all user requests and is the most critical node in the cluster. Since the WIStorageManager stores users’ “Personal Documents” on the middle tier, it should be on the machine with the greatest available hard disk capacity. It should always be run on cluster manager because there is only one instance of the Storage Manager module and it needs to be one of the first modules started.

Cluster Nodes
When ever possible, the WIGenerator or the BOManager should not be on the cluster manager but on a cluster node. These modules utilize much more RAM and CPU capacity then the other components and can degrade the cluster manager’s ability to handle and distribute user requests.

If only one module can be put on a separate machine and the deployment consists of both full-client and thin-client documents, the BOManager module should be the one separated from the cluster manager. The reason is a BUSOBJ.exe process will be started for every full client document that users may want to view or Refresh and for a BUSOBJ.exe processes take more resources then WIQT.exe processes. Full client Refresh in uses OLE Automation, which is CPU intensive. Each process should have at least 15 to 20MB of RAM allocated to it.

I have a good article outlining the Advantages and Disadvantages of Components Installed on a Single Server vs. Distributed Servers, so let me know your mail address if you would like to receive it.

Rgds
Maiden

 

[klyon]

Maiden -

Thanks a ton for your post!

I'll digest it when I get to work and may have some follow-up Q's, but wanted to send my emaila address so you can send that article.

klyon@thinklyon.com

Thanks again!

-Kris