It has been suggested that running the BigFix Audit Trail Cleaner will help improve the performance (or at least the load time) for the BES Console. I have tried this in my Dev environment (three total systems reporting into Dev wtih 31 total Actions currently). Before running the Audit Trail Cleaner, the load time for the Dev BES Console was about 1 min 40 sec. After running the Audit Trail Cleaner and then re-indexing the DB per a BigFix Forum Post (http://forum.bigfix.com/viewtopic.php?id=1153), the load time of my Dev BES Console was the same - no change. This seems like a rather lengthy load time for such a small environment.
I have contacted BigFix Support about this, but wanted to see if anyone else has used the Audit Trail Cleaner and has seen any significant improvements in their BES Console load times? Right now, my Prod BES Console takes between 3-4 minutes to load. I want to make sure that I see improvements in Dev first before trying this utility on my Prod environment. So far, no luck.
My experience with the tool was somewhat similar and before I saw an improvement I needed to have the DB maintenance jobs run. In fact performance was actually slower until those jobs had completed post cleaner.
I tried several things in my lab with very powerful machines and the conclusion that I came to was that with the console being single threaded it was just only going to load so fast… based on the amount of content that it has to load into memory. I personally would like to have the option to utilize more than one processors but that is the way it is right now.
If it really is multithreaded then that isn’t leveraged during the startup (load time). I posed the question to my support person and they also indicated that is was not multithreaded (was at one time) as most people used it on a terminal server.
I watched it closely only uses a single processor during that time of loading. I’ll look deeper but I was throwing every at it that I have found documented for speeding things up.
The way the console works is that there are 3 threads that do most the work: the “background thread”, which does the database queries, the “foreground thread” that carries out duties to take info and update the session stores or other duties, and the “UI thread” that responds to you as you click around the application. During loadup, the background thread is the busiest as it takes data from the database. We could theoretically make multiple background threads, but they aren’t completely parallelizable because there is an ordering of the work that needs to be done…
So I guess in summary, there are probably more things we can do with multi-threading that will help with common console activities, but we have already take advantage of some of the “low-hanging parellelizing fruit” and in many cases the CPU is not the bottleneck (usually it is the database) so more threads won’t always help…
My bad!!! I was using the term threading when I really should be discussing processor affinity or how an application will distribute itself with its threads over the hardware. Having threads tied to a single processor is not necesarily a bad thing given the architecture of the newer multi processors based systems. So the compliled model may align well to that since it is very likely that the console threads are sharing memory, but if the console was more aware of the hardware it could split those threads and perhaps have mutiple background threads using multiple cores of that same processor thereby speeding up load times without a shared memory penality.
As with the CPU vs. DB being the bottleneck, I agree that DB has often been the bottleneck but I seeing that shift as Bigfix has made improvements there and with the newer SQL server and hardware possible my focus and perhaps others has us looking at the console closer.
I’ve not doubted that you are always looking for ways for improving preformance. I’m usually pleased with the amount of new capability and improvements and the rate that they are released, and I feel that Bigfix does listen well and makes good decisions on how to address the needs. So don’t get me wrong, I’m just looking for ways to have something that is great get even better.
Load times of the console are the most common complaint that get from my users, and the second being refresh or console updating. I’ve got a 16-way server that is hardly breaking a sweat for the and of the BES Server or SQL work, but any console launch will peg a processor for the few minutes it takes to load based on the users data context.
So my two cents would be just to encourage more work in console optimizing so that console startup and refresh of content would leverage the platform.
thanks again Ben … and I’m not sure how I would do what I do without Bigfix.
Unfortunately, I did not see any BES Console load time improvement in my Dev environment due only to the Audit Trail Cleaner. I did discover in my Dev instance that 60 seconds of the 100 second load time was due to the Unix/Linux related Sites that I had loaded. After I unloaded them, the Console loaded much quciker. However, we do not have these Unix/Linux related Sites loaded in our Production instance.
In my production instance, I have already excluded the BigFix folders from AV scanning.
Update - I did finally manage to run the BigFix Audit Trail Cleaner and then the DB reindexing scripts against my producton instance. Before this was done, I was experiencing BES Console load times of about 4 min 30 sec. After running the utility and reindexing, my BES Console load time dropped to 2 min 30 sec. This is still longer than I would hope, but is a big improvement!
Now I just need a utility to automatically delete Stopped or Expired Actions from the BES Console. This should have switches for # of days so it can be used to delete these actions after N days. Then all of my maintenance can be automated.