What's new in WebSphere MQ Explorer V7.1: Part 3
mattchapman 1200004X8B Comments (2) Visits (9123)
This series of blog articles has been looking at new features in MQ Explorer. Part 1 covered the improved packaging and usability improvements. Part 2 shows how MQ Explorer works with multiple installations of WebSphere MQ on the same machine. In this third part I'll give some useful tips when working with larger numbers of resources in MQ Explorer, and in particular show some of the recent improvements made in this area in WebSphere MQ V7.1.
The phrase "larger number of resources" is rather vague so let's pin things down a little! For the purposes of this article I'm going to look at a scenario of connecting to around 100 queue managers from MQ Explorer (typically these would be remote queue managers), and each of these queue managers could contain a number of objects, let's say 1,000 queues. A different approach is likely to be required if things go significantly above this - for example you might need to monitor many thousands of queue managers but you would then typically connect to specific ones as required. It would be very time consuming to connect to and examine all of them in MQ Explorer!
Even if the rest of your deployment remains on MQ V7.0.1 or earlier you can still grab MQ Explorer V7.1 from SupportPac MS0T, as it will connect to the earlier level queue managers. I will however include some MQ Explorer V7.0 tips for anyone that can't move up yet.
Let's start by looking at a queue manager with 1,000 queues. I did a few stopwatch timings on my fairly new laptop, so although not completely scientific it should give you an idea of the differences (of course many variables come into play so your mileage may vary). Clicking on the queues folder in the Navigator view will retrieve the list of queues and their attributes, sort them, then construct the table used to display them in the Content view. I used a remote queue manager on a local network, obviously more distant networks with slower links would take more time. The whole process took about 8 seconds for me on V7.0.1 but only 4 seconds on V7.1 - twice as fast!
Many Queues Example (click image to enlarge)
With a fast and/or local network, quite a lot of the time is spent building the table with all the attributes shown. However there are a large number of attributes and you're unlikely to be interested in all of them. You can configure your scheme for queues (and other objects) to only show the attributes you're interested in. This will speed up the display of the table. In V7.1 the default schemes have been carefully pruned (for queues and channels) to show only the more frequently used attributes. You can always right-click on a queue and view all of its properties, and you can edit the scheme if you need to see a particular attribute. If you're staying on V7.0, you can edit the scheme yourself to reduce the number of attributes shown.
You can also speed up the display of tables if you don't need the objects to be sorted. You can do this by going to the 'Window > Preferences' menu and deselecting the option to 'Automatically sort tables in content view' on the WebSphere MQ Explorer preference page. This will result in the tables populating in less time, you can then apply the required filter or choose which column you want to sort the objects by.
Now let's look at handling 100 queue manager connections. To add them in MQ Explorer, either use the Add Remote Queue Manager wizard or import a previously exported list. To connect to all of them you can use multiple selection, but on MQ 7.0.1 this took over 5 minutes for me using the default settings! MQ 7.1 uses a single dialog for the whole operation and took just 7 seconds, quite a difference!! If you're staying on V7.0 you can change the Preference to reduce the minimum dialog display time to zero, this will speed up many operations, including reducing the multiple connection time to 53 seconds, still quite a bit off the V7.1 time though.
Refreshing the Navigator view is a common operation, it happens when the refresh button is pressed and whenever there are changes to be shown. As a quick test I connected to one of the 100 queue managers then disconnected. This operation, including the required two refreshes, took 60 seconds on V7.0.1 but a mere 4 seconds with V7.1! This improvement is the result of significant internal changes to the Navigator view. For anyone familiar with Eclipse components, the Common Navigator Framework (CNF) is now used.
If you're using V7.0, the technote entitled 'Improving WebSphere MQ v7.0 Explorer performance' provides the suggestion of disabling the Sets functionality in MQ Explorer. This helps the responsiveness when handling many queue managers. Now with the improvements in V7.1 this step is no longer necessary. In fact the Sets functionality can now be really useful to group the queue managers into meaningful classifications. To create a new Set, right-click on the 'Queue Managers' folder and select 'Sets > New Set..'. A manual set is one where you explicitly choose the members of the set. You can do that either by using drag and drop to arrange your queue managers into groups, or by using the set membership dialogs. An automatic set is one where you define the rules for set membership, for example "all z/OS queue managers", or "all version 7 queue managers". When you later add new queue managers to MQ Explorer, they will automatically appear in any sets whose rules match. A queue manager can of course appear in more than one set, and there is a predefined set called 'All' which naturally shows every queue manager, so you can still see queue managers that are not in any other set.
Queue Manager Sets Example (click image to enlarge)
Finally, startup time has also been improved, by a couple of seconds in my test. This is partly due to the repackaging changes described in Part 1 of this series, and also due to a change to perform most of the initialization work on a background thread so that the main window opens sooner.
Please let me know in the comments if you try MQ V7.1 and notice similar improvements yourself - include how many queue manager connections you have. Also, are there any aspects of MQ Explorer functionality where you feel there is still significant scope for performance improvement?