Have any one tried Deflate or GZip compression tech to improve the performance of Infoview pages in BO XI in Windows server.
We are literally facing the performance issue (mainly Login delay issue) for our environment which is on BO XI SP2 FP2.6 The environment is having a user base of 16K.We have SSO authentication enabled in our environment configured with IIS-Tomcat bridge.
I tried to search for deflate or GZip and found few lines of codes for GZip. I implemented them in Tomcat Server.xml file but to no luck. Even I was not able to figure out whether the compression is really coming to effect.
Looking at the size of our environment we are definitely looking to horizontally scale it, however if the compression can be acheived in Infoview that will be really great.
Our environment is a clustered one with 3 servers forming the cluster. We do use load balancing with Big IP routers in our environment. So that part is already been taken care of.
Just an additional information, our environment is a customized one in which almost 11k out of 16K users use to go though cutomized pages (Disclaimers, roleselector pages) before entering to the infoview. To acheive this functionality, the backend SDK code actually runs a query to validate if the user that is logging-in belongs to those 11K users or not. If not, then it will take user directly to infoview page else it will take them to disclaimer page or role selector page based on requirement.
Initally when we started this new environment with 4 K users, the login response was close to 8 seconds. Gradually the response started increasing and now its close to 15 Secs when we have almost accumulated 16K users. Becuase our users operate from different locations across the world so this figure use to vary across location. The lowest I have seen so far is 15 seconds. In future its going to be worse .
We tried to add index and tune query at the backend table but that didnot help us much. So the option we are looking for now is to use the compression techiques to improve the login performance.
I have seen there are many instance in which these compression techiques has really helped, so just trying to figure out if anyone has any input on this.
The gZip compression will be helpful when you have content on the page. It may have little contribution towards improving login response time.
Have you tried to run direct queries against the db to see how much time does it take to find out if a user belongs to those 11k users or not? If not, you should start there and then look at anything else. If the query itself takes 10 seconds to get result, gZip will be of no help.
HI I don’t have direct answer to your problem but when we have similar issue i took the help of network team to improve bandwidth as the main issue is the network latency between different countries. Netwok teams might use some kid of snifer tool to track the issue.
Cashworth is correct in his saying. It’s the CMS query that is taking time to execute, rather than network. That is contributing to the delayed login response.
Infact we use GZip and Deflate options in our environment but the response improved by 2 seconds which is not that great. :?
We are not even hopefull of getting any answer from BO Tech support on Deflate or GZip options. Becasue when it comes to customize thier code,they always prefer to take back benches
But incase anyone is getting any better idea to improve the login performance, they are welcome to share it.
My environment is different than yours but this might be of some use to you. I have 90,000 users in our system and our logon time is still under 5 secs. One thing that helped alot was changeing the settings for the CMS cache in the CMC. If you set it to something like 25000 it will have all the users cached in its memory instead of having to query its database.
Are you referring to
CMC->Servers -> Central Management server -> Single Sign On Tab
In the Single Sign On tab there is something called “Number of Seconds Before the Contents of the Cache is Expired:”. The value is set to 86400 seconds (24 Hours) in my environment.
So if I go by that, my environment can cache user information till 24 hours. Reducing it to 25000 seconds (7 Hours) will result in more frequent quering of database hence more delay in login.
Sorry i thought you were on XI 3.0. For you its a registry setting for how many objects the Cms will actually hold. It will be something like this HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 11.5\CMS\Instances…(there might be a cluster name in here)…[b]MaximumObjectsToKeepInMemory[/b]. Dont worry about setting it too high. I havent noticed any memory space issues or anything like that. It should make it so now the cms will have everyone cached and wont have to query the database for the user. Right now what is probably happening is it is searching its cache and upon not finding the person it has to then go to a second step of querying the database for the user.
Its a command line parameter in the properties section, it goes at the end after whatever else is typed there. You just put -maxobjectsincache 100000 or any number you want at the end. Its also in the Administrators Guide under the server command lines section.
(BOB member since 2007-08-16)
.
(BOB member since 2008-07-09)
(BOB member since 2002-09-13)