Login Brokers (L)
The login brokers panel shows detailed data on client/server login brokers. Not all information is available in older versions of OpenEdge.
Note that typically, the primary broker doubles as a client/server broker, though this is not always the case. Whether it is preferable to segregate client/server brokers from the primary broker or allow the more common double-duty is debatable.
|ProTop RT Label||Alertable Metric*||Description|
|Typ||N/A||Type of broker service. See table below.|
|IPver||brokerIPVer||TCP/IP version 4 or 6 broker|
|PID||N/A||Operating System process id number|
|-S||N/A||Name or number of the service used by the broker process|
|-minport||brokerMin||Lowest port number to use when spawning server processes.|
|-maxport||brokerMax||Highest port number to use when spawning server processes.|
|PendCx||brokerPCT||Any pending connections, which indicates a problem with a connection|
|-Mm||brokerMm||Message buffer size for 4GL client/server communication|
|-Mpb||brokerMpb||Specifies the maximum number of servers that the broker can start to serve remote users|
|-Ma||brokerMa||Specifies the maximum number of remote users per server process|
|-Mi||brokerMi||Specifies the minimum number of remote users per server before the broker starts another server|
|Cnx||brokerCnx||Number of clients currently connected to all servers spawned by the broker (OE11.5+ only)|
|CNX%||brokerCnxPct||Number of clients currently connected to all servers spawned by the broker, as a percentage of the maximum (OE11.5+ only)|
|SQLTrc||brokerSQLttlg||Indicates whether or not SQL tracing is active|
|SQLWUp||brokerSQLwup||Indicates whether automatic SQL Width Update is active or not|
|SQLcurs||brokerSQLcurs||Number of SQL cursors|
|SQLStack||brokerSQLstck||SQL Stack size|
|SQLstmt||brokerSQLstmt||SQL Statement cache size|
|SQLtmpb||brokerSQLtmpb||SQL Temp storage buffer size|
|SQLtmpd||brokerSQLtmpd||SQL Storage temp disk space|
|SQLtmpz||brokerSQtmpz||SQL Statement storage page size|
*Requires data collector "BrokerConfig" in pt3agent.cfg. With the commercial version of ProTop, you can configure alerts using the metric names in this column. For a full list of metrics, see the Alertable Metrics section.
Types of Broker Service
|SHM||Only shared memory connections on the primary broker|
|4GL||Broker for only 4GL client/server connections|
|SQL||Broker for only SQL connections|
|Both||Broker for both "4GL" and "SQL" connections|
Insight into Login Brokers
-Mm: The default value of 1024 is always too low. Benchmark testing shows that a value of 8192 provides most of the performance advantage, though setting this to 16384 or 31768 (the maximum value) is also acceptable. CAREFUL: prior to OpenEdge 11.6, clients were required to have the same -Mm startup parameter as the server to which they were connecting. In modern versions of OpenEdge, the client automatically adjusts to the server's -Mm value.
-Mi/-Ma/-Mpb/-Mn/-n: The interplay between these parameters is very important and often misunderstood. The first three (-Mi/-Ma/-Mpb) are broker parameters and can be different for each broker. -Mn and -n are global parameters.
To begin, you must know how many concurrent shared memory, remote 4GL and remote SQL users you need to support. For this example, let's assume 100 shared memory, 100 4GL client/server and 100 SQL.
Before OpenEdge 12, 4GL server processes were single-threaded, serving their users using a round-robin algorithm. It was therefore preferable to limit the number of users per server to 5: -Ma 5 (max users per server). Today, we almost always set -Mi to 1 (minimum users per server). There are use-cases for a higher -Mi. Therefore to support 100 4GL client/server users, we need at least 20 server processes: -Mi 1 -Ma 5 -Mpb 20.
SQL servers and OE12+ 4gl servers are multi-threaded, so we don't have this round-robin limitation. Theoretically, we could start one server process and let it spawn 100 threads to serve the 100 SQL users. In practice, though, if the one server process was killed for whatever reason, it would disconnect all our users. Better to split them them across multiple servers: -Mi 1 -Ma 10 -Mpb 10. CAREFUL: there was a bug in 10.2B0x (before SP8) and early 11.x versions which required a value no greater than 5 for -Ma.
The -Mn parameter is the total number of server processes: 20 4GL servers + 10 SQL Servers + the 2 brokers = 32. We suggest adding some buffer space to that value, in case you need to spawn a new broker process: -Mn 40.
Finally, we need to set -n: the total number of connections. 100 shared memory users + 100 client/server 4GL users + 100 SQL users = 300. But the server processes also connect to the database! That adds another 40 (from the -Mn value). Again, we suggest adding a healthy buffer to this value: -n 400. Note that connections do not equate to licenses. Setting -n 400 does not necessarily mean that you need to purchase 400 Enterprise Database licenses.
End result: 1. Primary broker: -Mn 40 -n 400 2. 4GL login broker: -Mi 1 -Ma 5 -Mpb 20 -ServerType 4GL -Mm 16384 3. SQL login broker: -Mi 1 -Ma 10 -Mpb 10 -ServerType SQL
Note #1: There are a number of -prefetch* parameters that should also be used. Search our blog page for articles on network performance.
Note #2: YMMV. While these values are likely valid for most environments, there are always special cases. Please don't hesitate to ask on the Progress Community Page or ask the experts.