LBI login and dashboard loading getting slower all the time...

I don't know your set up but is there anything in the websphere logs telling you of issues. One thing I have noticed (we have LBI residing in our protal window, not off a bookmark with DSSO configured) that is if we have issues most of the time I can trace it to websphere, hung threads, etc.

Also see if there is any errors in the LBI logs.

Is the performance issue occurring 100% of the time upon every login throughout the day? Or, perhaps is it happening to one individual at a certain time of the day, such as first thing in the AM?

Typically the first person that logs in to the system after a syncronization occurs will experience a performance hit. Subsequent attempts should be fine.

May I presume DSSO authentication is being used? I'd be curious to see if this component is the culprit by turning of DSSO and seeing if the performance issue is gone. At least at that point you'll know where the issue may be.

If you are using DSSO and have a large number of users within Lawson, are you utilizing the LBI Users field within the Configuration Assistant? These are some obvious things that come to mind. Also, is it just login time or overall performance? Couldn't tell from your post. Could also be non sufficient resources on your hardware or perhaps Websphere could need tuning.

I work with mjcindc and he asked me to chime in with the information you requested.

The slowness is 100% of the time, not just during login, but also loading screens, accessing reports, publishing reports, modifying security, etc. Rebooting or restarting services does not improve the performance. We have done performance monitoring on the hardware and there is very low utilization of all of the critical hardware components (cpu, disk, memory, and network). We are running DSSO, but do you think that is still relevant based on the above information? We have previously looked at Websphere tuning, but we will investigate it further. Do you have any other suggestions?

Wow, doesn't sound too good..What kind of resources are on this machine? Are you virtual?

Can you tell me a little about your architecture? Everything on one box? Is everything in-house or are you hosted? Using SSL?

Thanks.

We have two dual core Xeon 3.0 Ghz processors and 8 GB or RAM. We are not virtual. We have one box dedicated to LBI, one dedicated to LSF, the Lawson portal is running another box, and the SQL 2005 database is hosted on another box. Everything is in-house and we are not currently running SSL.

Thx

Hard to say without being able to get in and look around. Something definitely is not right. My approach would be to first look at how Websphere is tuned.

Hello,

I'm a newbie to the forum. Here is a couple of reasons our LBI page is slow to load sometimes. 1) Virus scanning - we had to exclude the websphere directories and CRAS server directories from virus scanning to improve performance. 2) Data Execution Prevention (DEP) My Computer >> Properties >> Advanced >> Performance Add the Crystal Report Application Server in the exceptions list.


Please keep me in the loop with your discoveries. I'm at joanna.bledsoe@jhsmh.org if you want to network.

I would increase your websphere heap size, in-memory count and thread pools.

for in memory-count:
navigate to servers > application servers > your LBI server > session management
adjust the maximum in-memory session count up (double it and decrease as you test)

for thread pool:
navigate to servers > application servers > your LBI server > additional properties > thread pools > choose web container
adjust the min and max thread sizes. (double them and decrease as you test)

save changes to the master configuration

My initial guess would be that the web server / app server (i.e. WebSphere or Tomcat) are leaking memory. As a simple test, try rebooting the LBI server and see if it speeds up. Also should look at log files for WebSphere/Tomcat, etc. as well as Lawson. As they grow larger and larger, things get slower and slower...

Also make sure that Websphere is patched appropriately according to your LBI level.  Most important, make sure you're applying the Fix Pack for the SDK.  If it is a memory leak I have seen the SDK FP resolve.

We had this same issue in the past. We found with help from CASE that the slow login time was due to the number of dashboards we have. Even if a given user only has access to say 10 out of our 200 total dashboards, the data for all 200 of the dashboards is loaded each time a user logs in. This got rectifiec when we upgraded to LBI 9.0.4.2. We also had general slowness within all of the LBI screens. We worked with CASE on this as well. We determined that we needed to add indexes to a few of the ERS tables as follows:

The following is a list of your three largest tables in Reporting Services, approximate record counts, and the indexes that should be added to those tables. For some functions in RS the response time improvements should be signficant (e.g. saving data settings on a report). The indexes for the ERS_REPORTACCESS table are the same as I provided to you previously, but it appears that they were not actually added to the ERS database you sent me.

ERS_REPORTACCESS (~ 5 million records)
CREATE INDEX IDX_REPORTACCESS_REPORTID ON ERS_REPORTACCESS (REPORTID, INSTANCEID)
CREATE INDEX IDX_REPORTACCESS_ACCESSVALUE ON ERS_REPORTACCESS (ACCESSTYPE, ACCESSVALUE)
CREATE INDEX IDX_REPORTACCESS_JOBNAME ON ERS_REPORTACCESS (ACCESSTYPE, JOBNAME)

ERS_REPORTATTRIBUTES (~ 3 million records)
CREATE INDEX IDX_REPORTATTRIBUTES_ATTRID ON ERS_REPORTATTRIBUTES (ATTRIBUTEID, REPORTID)
CREATE INDEX IDX_REPORTATTRIBUTES_REPORTID ON ERS_REPORTATTRIBUTES (REPORTID, INSTANCEID)

ERS_REPORTPERMISSIONS (~ 1 million records)
CREATE INDEX IDX_REPORTPERMISSIONS_REPORTID ON ERS_REPORTPERMISSIONS (REPORTID, INSTANCEID)
CREATE INDEX IDX_REPORTPERMISSIONS_ACCTYPE ON ERS_REPORTPERMISSIONS (ACCESSTYPE, ACCESSVALUE)


This greatly improved performance within LBI!


Thanks,
Robert

Good stuff Robert. Thanks for the info.