OSI/MHS Configuration and Management Manual

Sizing and Tuning Your OSI/MHS Subsystem
OSI/MHS Configuration and Management Manual—424827-003
8-11
Optimizing Routing
Optimizing Routing
To plan for efficient routing by OSI/MHS, it is important to understand the basic routing
principles of OSI/MHS, as described in Appendix E, Routing in OSI/MHS, of this
manual. Also review the part of Section 9, Troubleshooting Your OSI/MHS Subsystem,
that describes and illustrates message tracking with accounting event messages: the
use of accounting events is one of the best ways to expose the routing patterns in your
subsystem, including the overhead for distribution lists and closed user groups.
Every ROUTE, APPL, DLIST, DLISTMEMBER, and CUGMEMBER object has an O/R
name defined for it. The form of the name determines how OSI/MHS routes messages
to the object. In planning the O/R name attributes that are to define these objects,
there are several guidelines to follow:
•
For best performance, include only enough name elements to make the route
unique. For example, the route-selection criteria should not include a personal
name if the organization name is sufficient to make the route unique. For
mnemonic names, this approach is called hierarchical routing.
•
When possible, use specific routes rather than catch-all routes. A catch-all route
(in which every field is a wildcard) affects performance, security, and costs. It
affects performance because it is found last in the routing database, so a general
route requires the largest number of I/O accesses when searching the database. It
also has security implications because it sends all the messages somewhere; this
fact is also reflected in the costs that get billed to you.
The next several paragraphs mention special considerations for links and routes, for
APPL objects, and for distribution lists and CUGs.
Defining Links and Routes
In addition to the O/R naming considerations mentioned above, the following
considerations apply to definitions of MTA and ROUTE objects:
•
Define enough links to an adjacent MTA, and enough routes to the same
destination through different MTAs, to provide fault-tolerance and load balancing.
Number of entry manager processes per GATEWAY
object
5
Number of wait manager processes per GATEWAY
objects
1
Number of RTS associations 20
Number of RS associations 30
Number of LO associations 30
Table 8-1. OSI/MHS Subsystem Capacity Limitations (page 2 of 2)
Subsystem Component Capacity