Article

How to improve Client Server Performance

« Go Back

Information

 
Article Number000001215
EnvironmentProduct: Progress
Version: All supported versions
Product: OpenEdge
Version: All supported versions
OS: All supported platforms
Question/Problem Description
How to improve ABL Client Server behavior in OpenEdge?
How to improve 4GL Client Server Performance in Progress?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution
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

GENERIC FIND
 
One round-trip to request record/get the record
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.

FOR EACH - NO JOIN & NO SORT
 
NO-LOCK
Fetch the first record with one round-trip then as many records as it fits on a message per round-trip. 
Can be hundreds of trips for small records and big Message Buffer Size (-Mm) for example. See Article P176713, Is the number of records packed into a network message affected by the use of the NO-LOCK qualifier in a query   

NO-LOCK NO-PREFETCH
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.

Any lock inside of a transaction 
One roundtrip per record, as locks will be held until end of the transaction.

FOR EACH WITH SORT & NO JOIN

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.

FOR EACH WITH JOIN & NO SORT
This behaves like nested FOR EACH statements and will generate the same traffic as:
 
FOR EACH customer SHARE-LOCK:
    FOR EACH order OF customer NO-LOCK:
    ...
    END.
END
.

FOR EACH WITH JOIN & SORT

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.

OPEN QUERY
 
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.

CREATE
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.

UPDATE

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.

DELETE

One round trip to delete the record.
One round trip to delete each key.

UPGRADE FROM SHARE-LOCK TO EXCLUSIVE-LOCK

Requires one round trip.

WHEN THE RECORD IS BIGGER THAN THE Message Buffer Size (-Mm) PARAMETER

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.
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.

CONNECTION AND TRAFFIC
 
Client/Server connections can generate a lot of traffic.
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.

EXECUTION IN CLIENT/SERVER

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.
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.

CHECKING TRAFFIC WITH PROMON
 
Start a database in client/server mode having only one remote user connected to it.
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.

THE APPSERVER ADVANTAGE
 
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..
Workaround
Notes
References to Other Documentation:

Progress Article(s):
000001387, Progress Behavioral Differences Within a LAN vs. WAN 
000015987, Is the number of records packed into a network message affected by the use of the NO-LOCK qualifier in a query
000019803, What is the -Mm parameter?
000031154, Parameters to tune Networked Communication.   
000021563, How to enable message compression between the OpenEdge client and AppServer?

VOCABULARY for this Document

BANDWITH
How much data can be sent through a network at the same time.

DELAY
How long the information takes to travel through the network.
Usually terrestrial links have low delay while satellite links have high delay.
A congested network can have a high delay as well because of the need for messages to wait until the next hop is available to send the message.

ROUND TRIP
This is directly determined by the delay of the network links, not by bandwidth.
Every time the client sends a network message and waits for an answer the message needs to travel all the way from the client to the server and back. In a slow WAN, this can take as much as a couple of seconds. This a critical unit that is usually outside of the developer's control and that will make all the difference in performance.

PROTOCOL

TCP/IP
Is intended for the Intranet/LAN and is the fastest.

HTTP
Is slower than TCP/IP  due to wrapping of the ABL packets and is intended for use where tunneling is required over the intranet/Internet.

HTTPS
Is slowest of the three protocols due to the added security/encryption (ssl)

UDP
Is used for communication to and from the NameServer only, all additional communication is done with one of the above 3 protocols.

NETBIOS
Not really a protocol, just an API that can be run over another protocol for example TCP/IP, SPX, NETBEUI

MESSAGE
When Progress sends data through the protocol, it looks at the -Mm parameter set (if none is set it takes the default: 1024 for TCP) and tries to fit as much data in that number of bytes as it can. If it succeeds in putting all of the data you are sending into the 1024 byte space then it then prepends the message with 20 bytes of data as a header and sends it through to the database. If it can't put all of the data into the defined message size (-Mm) it will send multiple messages each the size of the -Mm parameter + the 20 byte header. Depending on the situation - zero data might need to be sent so in type of situation only a 20 byte header will be sent. The -Mm is a maximum size limit. The buffer itself is not padded to extend to the maximum defined size. Depending on the Protocol implementation of the system the actual datagram size may be larger than the 20 byte header + the message size due to whatever additional data or encapsulation the OSI model requires.
Attachment 
Last Modified Date12/14/2017 9:51 PM


Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025