Question Direct connect vs client/server.

ron

Member
11.7.4 on Linux

Hello DBAs,

Over a long period working with Progress, systems I have worked on have used a very straight-forward "rule" -- local users connect via "direct connect" (ie via shared memory) -- and remote users use client/server connections.

However, in the system I work with now it uses client/server connections in most cases -- even for local users.

A client/server has a higher system overhead -- and is therefore (to me) something to avoid ... so is there any good reason why one would choose to use client/server connections for local users?

Ron.
 

Cecil

19+ years progress programming and still learning.
Years ago we did some performance testing found the shared memory was ~33% quicker.
We then adopted the AppServer an much as possible.
I have work at an enterprise organisation where the desktop application we exclusively Appserver which meant that we could utilise OpenEdge 10.1B WebClients 10.2A cutting down on licencing cost.
 
Last edited:

ron

Member
I should have explained a bit better. Yes, of course, a local user must use a client/server connection for getting at an AppServer.

The situation I'm dealing with is users who simply access a DB using a character-based application.

Ron.
 

Cecil

19+ years progress programming and still learning.
I should have explained a bit better. Yes, of course, a local user must use a client/server connection for getting at an AppServer.

The situation I'm dealing with is users who simply access a DB using a character-based application.

Ron.
I agree with you. Shared Memory for TTY CHUI clients.
 

TomBascom

Curmudgeon
If your system is unstable and poorly managed (for instance sys admins routinely “kill -9” shared memory sessions…) the the use of client/server connections will insulate you from crashing… seriously, that is a real justification that some people advocate.
 

TomBascom

Curmudgeon
There are cases where c/s is actually faster than shared memory. Specifically if your workload is dominated by NO-LOCK queries. In that circumstance you are, basically, streaming data in large quantities so having two distinct processes simultaneously involved is an advantage.

But it only takes a few stray FIND statements to upend that apple cart.

Almost no real application will perform better using a c/s connection. With a bit of work you can run benchmarks that will put c/s in a favorable light but they don’t reflect real life.
 

ron

Member
Thank you Cecil and Tom. I believe you have confirmed my understanding.

I just wanted to be sure there was no "good reason" to use c/s that I was not aware of.
 
Top