Slow infoview log-on.

[gav12345]

Hi all,

Using BOEXI R1 with AD authentication. Despite having only about 250 potential users, it takes users between about 20-60 seconds to log on to Infoview, which to me seems very slow.

If they close down the browser and try to log on again immediately after the first successful attempt, it is usually (but not always) much faster.

There are usually only about 2-10 users logged on at one time.

The BOE XI server is a good spec & should far exceed the XI hardware requirements.

Does anyone have any ideas on this? It seems to me as if the AD authentication is slowing things down, but with so few users and no problems logging on to the network otherwise, this doesn't seem to make sense.

Thanks in advance, Gavin

 

[hilfy]

How are you configured? Everything on one server or is your web server separate from the report server? If they're separate, is there a firewall between the web server and the report server? Where's the CMS database and what kind of database is it?

What's the network latency between the servers - web, report, AD and CMS database? Is the AD server on a "good spec" box? What about the CMS database?

There's a communications bottle-neck somewhere, but that's hard to diagnose through a forum like this. You'll probably need to get your networking folks involved to do some sniffing to find out where it is.

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.

 

[gav12345]

Hi hilfy,

Everything is on the same server. The CMS database is just the standard SQL Server variety, again on the same server. The server is a good spec and should easily meet the demands placed on it.

I'm afraid I don't know what the network latency is, not really my area. Is there an easy way to figure this out or should I be speaking to the network admin? I don't think there is a problem with the AD, we're a very large organisation and logons seem fine otherwise.

I think you're right - I should be talking to our network chaps. If you've any other suggestions I'd appreciate them...otherwise thanks for your input.

Gavin

 

[hilfy]

If everything is on the same server, including SQL Server, that may be part of the problem. There may be some contention over resources between the two sets of software.

I would open Task Manager on the server, make the window wider so that the Performance tab covers more time, go to the Processes tab and sort descending by CPU. Then have someone log in through Infoview however they normally do while you watch what's happening in Task Manager. See which processes are taking up the most CPU cycles. Once the login is complete, go to the Performance tab and see what the trend is for CPU usage. I suspect that at some point it's maxing out. If it is, you may want to consider moving the database to another server.

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.

 

[gav12345]

Thanks mate. I've had a look and its still mostly System Idle that is using most cpu - the others showing are cms, lsass and w3wp, but they don't seem too bad. The cpu useage does reach near maximum (briefly) the first time I log on, then quite quickly works its way back down to minimal. It barely shows a blip on subsequent log on attempts (if within a few minutes of first log on).

Unfortunately out network admin doesn't have many suggestions. - One of our AD servers had quite a few updates pending and he's restarted that, but this doesn't seem to have made a whole lot of difference.

Do you still think moving the database may help with this?

Gavin

 

[hilfy]

On my dev system where everything is on one server except the database, it takes about 20 seconds for the login to go through. On my production system (2 CMS cluster with the db on Oracle on a separate server on our main network and web server in the DMZ) it takes about 8 seconds.

When you log in, a couple of things happen:

1. The Web Component Adapter (WCA) starts a BO "session" and sends the login request to the CMS.
2. The CMS receives the login request, connects to the database, validates the user and retrieves all of the user's access rights along with the folders that the user has access to and information about the user's home page.
3. The CMS sends the user information back to the WCA.
4. The WCA receives the user information and then builds the folder list and the user's home page. If the user's home page is a dashboard, there's more communication between the WCA, the CMS, and other components to get the data for the dashboard and render it appropriately.

So, there are many things happening, all of which take processor time and memory. You will probably get a speed increase by moving the database to another server, but that's also going to depend on the specs of the database server and how fast the network connection is.

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.

 

[gav12345]

hilfy, sorry, just got this when looking through my older threads...for some reason I'm not getting notified of replies by email just now...

Thanks for that information. Spoke to BO support in the end and played around with a few configuration settings, but they essentially said that <30 seconds is an acceptable log on time. And since ours is now averaging closer to the 20 second mark, we're leaving it alone for now.

- Thanks again, Gavin