This Article explains how Progress generates traffic on a Client/Server LAN or WAN environment.
It will focus on what Progress sends and receives through the network and not how one specific network protocol would handle it. In other words: concepts that are largely protocol independent.
Every FIND, FOR EACH, OPEN QUERY, GET, PRESELECT, ASSIGN, CREATE, DELETE (all data manipulation statements) generates client/server traffic when the database is connected with the -H -S client connection parameters. Being aware of the above and knowing how much traffic each 4GL/ABL statement generates can make the difference in a fast versus a very slow networked application.SIMPLE FIND
FIND customer WHERE cust-num = 10 NO-LOCK.
No locking is involved.
One round trip to retrieve the record.
One more one way message to release the cursor.
Client ---> Server Requests record
Server ---> Client Sends record back
Client ---> Server Releases the cursor
One round-trip to request record/get the record
FOR EACH - NO JOIN & NO SORT
No extra message to request a lock (RECID finds don't allocate a cursor).
If the cursor will not be used again it is released immediately, if it might be used later it will only be released when the record goes out of scope which is done with a one way message.
SHARE-LOCKs are released with a one way message.
In a transaction no locks are released until the end of the transaction.
One roundtrip per record (not a very wise choice due to inefficiency).
SHARE-LOCK outside of a transaction
One roundtrip per record plus a one way message to release lock.
FOR EACH WITH SORT & NO JOIN
Any lock inside of a transaction
One roundtrip per record, as locks will be held until end of the transaction.
FOR EACH WITH JOIN & NO SORT
Will retrieve a list of RECIDs and sort keys as a prefetch FOR EACH regardless of sort type.
For example: Small sort keys and a large Message Buffer Size (-Mm) parameter may pack hundreds (or thousands) of records on a single network message.
Locks are acquired and released automatically by the server.
Progress then sorts on the client side and behaves like a regular sort but can't do prefetch.
Client sends RECID by RECID as the server returns each record.
If SHARE-LOCK outside of a transaction a one way lock release message is needed for each record.
This behaves like nested FOR EACH statements and will generate the same traffic as:
FOR EACH customer SHARE-LOCK:
FOR EACH WITH JOIN & SORT
FOR EACH order OF customer NO-LOCK:
Depends if the sort is only on the main table or not.
Can use a lot of round trips.
Not recommended, use nested FOR EACH statements preferably.
Will generate no traffic if SORT or PRESELECT isn't needed.
Will behave like the SORT phase of a FOR EACH if SORT or PRESELECT is required.
Then one round trip per GET (if the requested record is already on the queries cache, then no traffic will be generated).
A REPOSITION statement can behave like multiple GET statements or like a single one depending on whether the query is using INDEXED-REPOSITION.
No traffic right away.
When the first key is filled will:
Physically create the record with one round-trip.
Another round-trip to create the key.
Each extra key will use another round trip even if the whole record is created within a single ASSIGN statement.
Then will use another round trip to write the record when it is released.
Records are retrieved according to the rules presented before.
One round trip to update each key as needed even if all key changes are done within the same ASSIGN statement.
One round trip to write the new record.
UPGRADE FROM SHARE-LOCK TO EXCLUSIVE-LOCK
One round trip to delete the record.
One round trip to delete each key.
WHEN THE RECORD IS BIGGER THAN THE Message Buffer Size (-Mm) PARAMETER
Requires one round trip.
Progress will send one way messages until the end of the record is finished so the record is efficiently streamed through the network.
Apart from -Mm, further database startup parameters were added in OpenEdge 10.2B06 and 11.1 to tune Network Communication performance. See Article 000031154, Parameters to tune Networked Communication. TRANSACTIONS AND TRAFFIC
No traffic to open a transaction.
CONNECTION AND TRAFFIC
One round trip to commit a transaction.
Subtransaction UNDO will do the inverse operations so it can generate a lot of traffic.
A transaction UNDO is one round trip plus one extra one way message.
Client/Server connections can generate a lot of traffic.
EXECUTION IN CLIENT/SERVER
How much traffic that gets generated on connection depends on how many database objects are in the Database.
Using a local schema cache (SAVE CACHE and the -cache startup parameter), reduces the connection traffic to a couple of round trips and less data.
At each initial reference to each database table (without using schema cache):
One round trip to retrieve mandatory array, template record and ALL index information.
There is a schema lock that needs to be acquired in shared mode to be able to run any procedure that uses the database.
CHECKING TRAFFIC WITH PROMON
Any time a program that references a database runs, it will attempt to acquire a shared schema lock with one round trip plus one one way message to release it in the end of the program.
Start a database in client/server mode having only one remote user connected to it.
THE APPSERVER ADVANTAGE
Use the PROMON > R&D > Activity: Servers screen
View how many messages were received from the client and sent back to the server.
Run this with a controlled typical application test and record direct traffic metrics for the application.
Customers worried about client/server performance should use this screen to take measures especially if they are going to deploy on a WAN.
It takes just a couple of round trips to establish an AppServer connection and once this is established it is only one network round trip to execute each procedure that is RUN ... ON SERVER.
For every RUN ...ON SERVER:
The client sends a stream of messages (usually only one) with the input parameters.
The server executes the procedure and sends back a stream of messages with the output parameters.
While there are no parameters for regulating packet size for the client to the Appserver, Progress 9.1D08 introduced a new client switch "-mc" that allows the message between the client and the AppServer to be compressed..