Split your web content or not? Part 2 of 2

In the first part of this series, we looked at the mechanics of implementing a split deployment of the SAP BusinessObjects web tier by adding the Apache HTTP to offload static web content from Apache Tomcat.  In this second part I will go over the high level pro and con of doing the split.  There really is only one pro and con each worth discussing because each would be the main driver for or against splitting.

Disadvantages of a Split Deployment

Let’s look at the con of splitting the content.  The installer does not give you the option of splitting the content as part of the install.  You are forced to either deploy to Tomcat as normal or not deploy at all.  Deploying to Tomcat as normally done is the best thing to do.  This gives you a base of Tomcat only where you can test and most importantly to have a fallback option if the split proves to be too much to handle.  First you must install a supported version of Apache and get it working.  From there you have to manually predeploy the content in split mode using the web and application servers of choice.  This can take about 1-2 hours to complete.  Once that is complete you have to deploy the split content which can take another 1-2 hours.  This is all on top of the original installation time.  Then comes the real fun of setting up the Apache workers and the Tomcat AJP connector in to Apache.  This can prove to be very painful your first couple of times through it.  Now, with that being done and working you have your environment up and running.  Here lies the real rub in my opinion.  The next time you need to do an upgrade this all has to be done all over again.  In a development or test environment where you have more time and patience from your users the additional upgrade time can be prolonged if there are issues.  However, you’re going to be under a lot of pressure on the production upgrade because the time frame is short and finite, the system must be brought back online quickly.  Therefore, the main con of splitting the content is the additional complexity and the time it takes to perform an upgrade.  Test, test, and test before getting to production so you have a solid repeatable process in place and it makes it worth the risk.

Benefits of a Split Deployment

Now to the pro of splitting the content.  I’ve been around SAP BusinessObjects support for 13 years and have worked on some huge systems where users fight every little change.  It is an intangible benefit that cannot be measured with numbers, but I know from my experience that better performance directly correlates to better user adaption.  Users might already be resisting the move to a new version or even a minor upgrade.  If you put an environment out there that is slow and sluggish and they get the slightest bit down on it, your new environment and project is doomed.  Users will use the bad performance as the scapegoat to throw their hands up in the air and say “I can’t use this” and you won’t even get them in to testing.  Give them an environment that zips through screens, pops documents right open, and overall performs well and they’ll give it a chance and actually get to the testing phase.  This allows you to focus on the error resolution from testing versus trying appease users over performance.  Users can actually see the difference in going from just an application server serving all content to having it split across a web and application server.

This concludes my thoughts on the topic of splitting web content in SAP BusinessObjects BI4. I hope you have found this high level information useful in making your decision to do it your environment. Thanks!

Link to part one is http://evtechnologies.com/split-your-web-content-or-not/.

One thought on “Split your web content or not? Part 2 of 2

Leave a Reply