Please opine on your console response times.
- Very Poor
- Poor
- Acceptable
- Very Speedy
0
voters
After upgrading to the latest v11 platform the Console Performance improved
You also need to make sure your SQL is configuration are optimized
2 Likes
Oh, we have been down this road. We use NVM/e for root \program files and we use NVM/e for SQL data.
We have had architects say after examining our perfmon data, that our setup screams for performance.
The bottleneck is in the design of the console itself. Antiquated and needs to be rebuilt from the ground up. But most of us would rather have a single web console for all of Bigfix and have it scream for performance.
There is an idea for this already too, Vote for me now
Vote on that if you have not yet.
We have the cloud plug-in enabled and that was when the fun started, which as you recall was patch 4 of v10.
Been pretty much useless since.
We do have Multicloud running but it didn’t really have impact on console performance (I guess size of environment and number of cloud instances may come into the equation) but yea, bottom line is there will be a line that you can’t cross due to current design. For us specifically was remote consoles on user machines - the traffic over the WAN to colleagues in offices on the other side of the world was incredibly slow (there were users that had to wait 30-45 mins for the console to load up), so we opted to share the console via citrix on servers in the same location as the root server and that solved that problem. There are still colleagues that have to wait for console load times depending on how much data they’ve opted to add to their views and we also set console refresh rate to 10 mins due to amount of operators we have but generally that keeps somewhat decent console performance. Definitely a lot of room for improvement though!