Tuning BusinessObjects Enterprise XI 3.1 and VMware – Part 2

Here’s what I’ve accomplished so far.

Disable Unnecessary Windows Services

  1. I noticed that a process called cidaemon.exe was consuming a bit of resources. Sometimes I actually had several of these processes running. It’s a service that supports full-text searching on Microsoft Windows and this MSDN article (even though written for Windows SP) explains how to disable the service.
  2. Disabled the WinZip icon in the notification area. Probably doesn’t save much resources, but it was easy to disable and not often used.
  3. Used the SQL Server Configuration Manager to stop the SQL Server FullText Search and SQL Server Analysis Services (SSAS). Also set these to manual startup instead of automatic.
  4. Used the Windows Services panel (Start -> Administrative Tools -> Services) to stop the World Wide Web Publishing Service, which is IIS. Also set to manual startup instead of automatic.

Increase physical and virtual memory
For this one, I gently increased the virtual memory to 2.2 GB from its previous value of 2 GB. I also used the “recommend” setting for virtual memory, which was a bit higher than 3 GB. I still may increase the virtual memory to 4 GB.

Shut down unused BusinessObjects Enterprise servers
This section was tricky because, after all, don’t we want a functioning BusinessObjects system? But I’m generally teaching or demonstrating a subset of the functionality.

  1. Stop the Voyager server and clear the properties box that automatically starts it. I can easily turn this server and MS SSAS back on if I want to use them. Ditto for the List of Values Job Server.
  2. Created a new SIA with 4 new Explorer services, then removed the original ones. Used the Central Configuration Manager (CCM) to set the SIA startup property to manual for when I want to use it.
  3. Created a new SIA with 9 new Performance Management services, then removed the original ones. Used the Central Configuration Manager (CCM) to set the SIA startup property to manual for when I want to use it.

I’m considering upgrading the virtual machine itself from VMware 5 (created with VMware Server 1.x) to VMware 6.5, just to see if the fine folks at VMware have made things work better with fewer resources. But I’m holding off until I can assess the changes that I’ve made so far.

I would love to hear your ideas on how my virtual machine can run even faster. As always, feel free to post a comment.

Dallas Marks

Dallas Marks

I am an analytics and cloud architect, author, and trainer. An AWS certified blogger, SAP Mentor Alumni and co-author of the SAP Press book SAP BusinessObjects Web Intelligence: The Comprehensive Guide, I prefer piano keyboards over computer keyboards when not blogging or tweeting.

One thought on “Tuning BusinessObjects Enterprise XI 3.1 and VMware – Part 2

  1. So… ? What was the result?

    It wasn’t apparent to me from the entries, what was the guest OS? I ASSuME a Windows guest, but what version? And, how many core?

    One item repeated early on in the virtualization heyday was “separate spindle” — if you have only one physical drive, both host and guest (and guest apps) are fighting for control. Consider: SSD HD (almost “0” access time), separate HD, Running from a USB (well, not optimal, but hey, I like portable OSs so why not a portable VM?). Roll them together for a separate, external (USB) SSD.

    Also consider BOXI under a Linux (or possibly even OpenSolaris).

    Another good topic would be additional deployment options. Our environment requires Apps on specific drive (not OS drive), Web components on separate drive, DB on separate drive, etc. Not hard if you’re deploying to IIS and MSSQL, but if you try to take the R2 or 3.1 “bundled / bungled” install, hacking apart seems a bit of a problem. Their install (pre-3.1 SP2) didn’t take needing a different Tomcat (6.0+) nor a non BOXI-sub-directory into account. My poor attempts at hacking a config.TC6 and TC6.xml worked, but at the loss of WebI.

    Another good topic would be the steps to get Log4J to run… it’s not necessarily HARD, just a pain — and we couldn’t troubleshoot WebI’s issues until we had some useful logging.

    As much as I like BOXI, it’s getting to be a pain to plan upgrades / updated architecture.

Comments are closed.