Configuring a Workspace to use Parallel Queue Processors
Should I use parallel queue processors and if so, what is the best number of parallel queues to use?
When to use Parallel Queue Processors
Not all tasks that can be performed to prepare code for analysis can be run in parallel, for example, IMS Analysis should only be run on one queue processor and should only be invoked once all the Cobol programs have been fully processed. Once a program has been verified there are still processes that run to build the full set of relationships, so the queue can still be in use once verification has completed.
If IMS Analysis is then started against a workspace that has multiple queue processors available, it will be sent to an idle queue. In a single queue environment, a warning is displayed if the queue is not empty, but in a multiple queue environment, if all the processing has not completed the warning is not displayed. In this case, this will cause the IMS Analysis to fail as not all the required relationships have been generated.
Until recently TWS Schedules could not be parsed in parallel.
For parsing some of the languages like Java a queue processor is invoked, but it is not used. In those situations, the setting of the number of queue processors has no affect. For other languages like, C, C++ and VB, a the queue processor is used for processing the relationships generated by the parser, but not the parser itself. In this situation, having multiple queue processors is of little benefit.
Using parallel processors is most effective when parsing mainframe code such as Cobol, BMS Screens, JCL, Natural, PL/I and scheduler files. This processing can all be done using the Batch Refresh Process (BRP) which can be setup to run overnight to allow analysis to happen during the day. As the parsing has longer to run, you may not need to use parallel queue processors.
How many to use
This comes down to the number of CPU’s that are on the machine that is doing the work. This may not be the local machine as you may well open a Citrix or remote session to connect to the workspace before using Modernisation Workbench (MW) or Enterprise Analyser (EA).
The recommended number of queue processors is one per CPU on the machine in question. Running too many queue processors can lead to bottlenecks on the resources that the queue processors use which may make the performance worse rather than giving the speed improvements that are being sort.
It may actually make more sense to look at the performance of the machine that hosts the database and the network configuration between the MW/EA machine and the database rather than increase the number of queue processors. This could be where the real bottleneck is.