BES Consoles loading slowly?

Usage and Config Platform
1

(imported topic written by BenKus)

This post is meant as a discussion starter specifically for questions regarding BES Console load time.

The BES Console will take varying times to load depending on various deployment details. As the following attributes increase, so does the load time:

  • Number of BES Clients managed by the specific BES user.
  • Number of actions (non-deleted).
  • Number of Fixlet sites.
  • Number of properties.

Over time, you generally expect the number of actions to increase and also the load time of the BES Console (although not by a huge amount). This is one reason why we recommend cleaning out old unnecessary actions.

When the BES Console loads, it gathers up quite a bit of data from the BES database and loads it into memory. If caching is enabled, it first loads from the previous cache and then loads the rest from the database (keeping the cache on is highly recommended).

Load times can vary anywhere from 10-20 seconds for newer/smaller deployments all the way up to several minutes for the largest 200,000+ computer systems (when a BES administrator logs in).

Here are things that will affect load time:

  • If the cache is enabled under File > Preferences (by default, enabled), the BES Console should load faster and put less load on the server.
  • Fast network connections will definitely help the console load times. A 100mbps or 1 gbps network connection will load tremendously faster than a 10mbps network connection as expected.
  • If you don’t have enough memory, you will see tremendously slow load times as your computer pages memory to disk (you will also see a lot of hard drive activity after the cache loads, but before the console fully loads).

As with the case of general BES Console performance, a user connecting from a computer without enough RAM or on a slow connection will cause database locks that will drastically affect other users. If you tend to see good performance loading the console, but then “all the sudden” see poor performance one day, it is very likely caused by one or more BES Console users loading from a slow connection or being low on RAM and the SQL Server database will hold the table locks until their BES Console fully loads (in these cases you should get more RAM for the user or use a remote connection tool to load the console from a computer that has a faster network connection to the BES database).

Feel free to post console responsiveness issues here.

Ben

1 Like
2

(imported comment written by SystemAdmin)

A few other things to consider:

  1. When the BES Console is loading data from the database, the database may need to read from disk prior to sending the bits over the network. A high-performance disk for the SQL server will help seek times, we recommend RAID 1+0 for best performance. Also, giving SQL plenty of memory will help it cache data so that it doesn’t need to read from disk. Setting SQL to use over 2 gigs of memory on larger (30K+) deployments will help BES Consoles to load faster.

  2. The BES Console has to read the cache off the local disk. Higher speed disks on the local computer will help speed this up. Usually desktops are faster at loading the cache then laptops because laptops normally have slightly slower hard disks.

  3. The bottle neck in loading your BES Console could be local, on the network between your computer and the database or on the database server itself. It is important to identify where the bottle neck in your system if you are trying to maximize BES Console performance.