In article <6Uagd.793981$Gx4.45884 (AT) bgtnsc04-news (DOT) ops.worldnet.att.net>,
"Mark Merenich" <mmerenich (AT) worldnet (DOT) att.net> wrote:
Quote:
We are moving our Progress Server off site to a data center.
Now there will be 2 offices/networks connecting with Progress Client
Networking to the server at the
data center. The offices and data center have T1 lines.
Application is running slow over these connections.
Is anybody connecting remotely to a Progress Server? Any special
communication lines, Point To Point T1? VPN?
Any help would be appreciated.
TIA, Mark Merenich |
I have seen this before.
Really the application needs to be written in a better way. It is very
forgiving on a lan, but start loosing that bandwidth and things get slow.
Here are some examples:
Some people write:
FOR EACH CUSTOMER NO-LOCK
WHERE....
Well - that pulls ALL the record's fields over the line, even if that
data is not needed.
That needs to change to something like:
FOR EACH CUSTOMER FIELDS (Name, CustNum) NO-LOCK
WHERE....
Some people write:
FOR EACH CUSTOMER NO-LOCK...
FOR EACH Order OF Customer NO-LOCK...
This causes the join to happen at the client!!!
It should be changed to:
FOR EACH CUSTOMER FIELDS (Name, CustNum) NO-LOCK,
EACH Order OF Customer FIELDS (OrderNum) NO-LOCK...
which causes the join to happen at the server, and I believe the data is
better packaged on the way back.
This is just a couple of examples.
Like I said, the language is very forgiving on the programmer - that is
the beauty of a 4GL - but that doesn't mean the developer needs to think
about potential optimizations on what is happening "under the covers."
If you don't have source - you will need to try a different strategy:
1) Faster connection or bundled connections.
2) Try using a virtual desktop product so that all the execution happens
at the database side of the line, but the screen displays happen on the
user's side of the line. Something like http://realvnc.com/