Kbase P67993: How to use Secondary Login Brokers
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
19/03/2009 |
|
Status: Verified
GOAL:
How to use Secondary Login Brokers
GOAL:
Alternate uses for Secondary Login Brokers
GOAL:
How to use Secondary Brokers to balance TCP port load
GOAL:
How to use Secondary Brokers to provide different Client:Server ratios
GOAL:
How to use Secondary Brokers to debug client code issues
FACT(s) (Environment):
Progress 8.3x
Progress 8.2x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
FIX:
How many DBA's have wide varieties of clients? Host based, Local LAN, Wan? How many applications do different types of functions for different people (transaction processing, reports, batch processing)? How many people use one broker for Progress 4GL and one broker for SQL92? Not only can secondary login brokers be used for segmenting 4GL and SQL92 users but also for segmenting different types of tasks.
Not all clients use their application in the same fashion. People that perform simple lookup tasks and people who run large reports both work on the same remote client connection often see different performance. Some will say that the database is slow (their perception) while others say that performance is just fine. Both are connected to the same database so why the different perception?
Typically the user who perceives the database as slow are sharing the same remote client server with someone who is running a large report. The total volume of data that the report is requesting is heavily utilizing the time of the remote client server. Other users who are connected to different remote client servers (that aren't processing reports) would not experience a performance lag. For discussion purposes lets define a database startup command:
proserve -N TCP -S -n 200 -Mn 20
With this startup parameter everyone is handled the same. In this situation if a person running reports shares a server with 9 other people those 9 other people might be inconvenienced by that one user running a large report.
Consider defining a separate login broker for people who run reports. This would help separate the tasks and cause less lag for the OLTP users.
Example 1) Shows a primary broker defined for OLTP clients and a secondary broker defined for reports users.
proserve -N TCP -S -n 200 -B 12000 -Mn 24 -Mpb 18 -Ma 10
proserve -N TCP -S -Mpb 5 -Ma 3 -m3
This would change the ratio of clients to servers for both brokers and likely improve the response time of the transaction processing users. Consider also modifying the Message Buffer size so that Progress might try to use larger packets thereby decreasing the number of packets we need to send for data. In situations such as across a WAN this can make a substantial impact on large reports.
NOTE: -Mm has greatest effect for "For Each NO-LOCK" queries.
Example 2) Shows the -Mm 8192 on the secondary broker to change the message buffer size (Progress packet size) for transmissions
proserve -N TCP -S -n 200 -B 12000 -Mn 24 -Mpb 18 -Ma 10
proserve -N TCP -S -Mm 8192 -Mpb 5 -Ma 3 -m3
Furthermore the brokers could be configured so that report users might use the private buffer option so that their reports wouldn't impact the buffer pool as much.
NOTE: The client parameter -Bp requests a portion of the Database Buffer Pool (-B defines the database buffer pool when used for server startup). -Bp can not exceed the database server startup parameter of -Bpmax. -Bp can not exceed 25% of the cumulative total of the -B.
Another use for secondary login brokers which is little considered is in the area of debugging problems. When all clients are going to a single broker it becomes very difficult to identify certain problems. Different code trees blend together so you can't quickly identify if a problem is caused by the code from your 4GL clients or your AppServer connections or your WebSpeed agents.
As companies grow these days it becomes more common for systems to have thousands of clients. This can pave the way to problems not possible with smaller client loads. The operating system can actually be overwhelmed if
too many packets reach a TCP port. This is often termed a packet storm and most operating systems have means of handling this.
However if thousands of clients request conn.ection simultaneously to the same broker it might cause delays as the OS tries to handle all the packets. By adding multiple brokers you spread the load to multiple listener ports and thereby decrease the possibility of dropped packets if the OS receives too many messages reach the broker port simultaneously.
This is by no means the limit of uses for Multiple Brokers but it is a good starting point..