Client/Server on Wi-Fi - Forum - OpenEdge Deployment - Progress Community
 Forum

Client/Server on Wi-Fi

This question is not answered

Hey all,

Has anyone been brave enough to have a C/S deployment and using it via wi-fi connection?

We've been questioned about that, because our ERP performance is terrible like this, but is normal over the wired. A common report had a significant different of performance, using 1Mbps bandwidth, while on the LAN it was 6Mbps on avg. I was running it almost alone on that server. Bandwidth is not a problem, since I can have some file copied through SMB and using ~80Mbps.

Thanks!

All Replies
  • Its not bandwidth that is the problem.  It is latency and the number of sequential round-trips that are performed.  

    While saving a business document in our ERP , I've regularly seen *thousands* of client-server round-trips to the OE RDBMS database.  This is the nature of the OE database technology.  Almost everything happens on a row-by-row basis.

    As a quick check for latency, I'd suggest "ping"ing the server and reviewing the average round-trip times.

    In order to get a grip on the number of round-trips that are being made, I typically open task manager in windows and watch the increasing number of packets that are sent/received (image):

    I think your performance problems will grow proportionally to the (latency*unicasts).

    One trick that might help in troubleshooting is a trick that Progress tech support told me about.  You should *always* start your troubleshooting by running your application code on the same local server as the database - but when you do this, you must make sure to use "-H and -S" parameters for client-server connectivity - instead of using "shared-memory".  This trick will take the physical network out of the equation altogether (while leaving the OE client-server technology layer in place).  The performance of this configuration must be measured as a "baseline".  Then if you end up seeing bad performance over a remote network, then you must compare it to the baseline and that will tell you how much the network itself is slowing things down.

  • We run our CHUI app over WiFi without any major issues. But then CHUI is a lot less intensive than GUI. But there shouldn't be issues running over WiFi.

    It may be a good idea to look at tuning the various -prefetch parameters, making sure you have a sensible -Mm too. This will ensure the network packets are reasonably stuffed.

    Other aspects to consider involve reducing the amount of round trips by using local caching (Temp Tables/Classes or that ilk), or employing AppServers to do the work in a shared memory connection and then passing the result sets back to the user.

  • In the past, we never had much success running our GUI POS module over WIFI. When running client server the slightest network interruption would cause a disconnect from the DB.

    We have since re-architected our app and implemented an appserver with a better framework...much better.

  • The "chattiness" of the client/server protocol makes it *very* sensitive to latency -- on  localhost it's no big deal, a good fast LAN with sub-millisecond ping response times is also usually ok.  Wi-fi tends to have a lot more latency and congestion issues than a wired LAN.  Especially if it is heavily used.  Configuring wi-fi in a high-usage environment is very difficult.

    A WAN can get really ugly -- especially if you get routed through a satellite link :(

    And the whole Meltdown/Specter thing is not helping either -- the two classes of applications most severely impacted are those that make a lot of system calls and those that do a lot of IO (which is a somewhat redundant statement since IO and system calls are inseparable...)  A "chatty" networking protocol associated with a database is your classic  "perfect storm" :(

    --
    Tom Bascom
    tom@wss.com