Feedback
Did this article resolve your question/issue?

   

Article

Query performance with a join is very poor with client/server connection

« Go Back

Information

 
TitleQuery performance with a join is very poor with client/server connection
URL Namep120701
Article Number000148036
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
Query performance with a join is very poor
Query with a join run via a client server connection can be very slow.
Query with a client server connection can be up to 10 times slower than a shared memory connection.
A dynamic query performance is slow when run client server.
 
Steps to Reproduce
Clarifying Information
Example ABL Query with joins:
vcQry = "FOR EACH RoleResource FIELDS(RoleResource_ID Role_ID) NO-LOCK"
                      + " WHERE RoleResource.Role_ID = 7328,"
                      + "FIRST Resources FIELDS(Resource_ID) NO-LOCK"
                      + " WHERE Resources.Resource_ID = RoleResource.Resource_ID".

 
Error Message
Defect Number
Enhancement Number
Cause
This is expected behavior. It is due to the way query resolution is currently designed to work when a join is involved.
  • When there isn't a join and records are read NO-LOCK, the server can "read ahead" and pack lots of records into a single message. 
  • When there is a join and records are read NO-LOCK, table records are interleaved. The "read ahead" is limited to only those records that belong to a given parent.  This results in much more network activity and subsequently there is less advantage from the groupings of records per message. This can also exhibit higher database reads. 
Resolution
In some situations improvements in performance can be made using one or more of the following techniques:
  1. Modify the query to use PRESELECT instead of FOR
  2. Modify the query to use field lists.
  3. Modify the application to use an AppServer. Run the database and the AppServer on the same machine so the AppServer can use a shared memory connection. Run the query in a procedure that runs on the AppServer and returns the required records to the remote client as a TEMP-TABLE.

 
Workaround
Notes
Last Modified Date12/1/2020 5:32 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.