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!
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" :(