D
dbeavon
Guest
When the OE database runs across a client/server connection you need to watch packets per second first , and CPU next (on both sides.) The performance of the app really is all about the latency of those packets, and the time it takes to turn them around (RTT). For any OE ABL program that is running slowly, I typically expect to see my packets per second hovering between 6,000 and 10,000. Unless the code is doing FOREACH-NOLOCK scans, then the payload of those individual packets is extremely small. If you want to understand the performance characteristics of the protocol better, I highly recommend downloading wireshark and watching the I/O graph. If nothing else, it is somewhat cathartic and gives a way to pass the time as your queries are executing.... Below is the retrieval of ~1500 documents via client/server. Notice that it takes about 15 seconds and the packet exchange rate is over 10,0000 for the entire time. The first image is from wireshark and the second is from task manager. I think it is especially interesting that my "query" of these documents involves sending almost twice as much data to the database server as what I'm receiving. I'm not sure what the protocol is doing that requires so much data to be heading in the wrong direction... I'm curious to take a look but haven't had the chance. One last thing about the RTT. If there is some small amount of CPU (even a dozen ms per record) that is being used on the client then this can make all the difference between a packet rate of 5,000 and 10,000 packets per second. That is why CPU needs to be monitored as well! This is probably not helpful to a Linux customer. But one thing to point out is that the OE database does have an ODBC interface. So if you are running ABL on Windows with the CLR bridge, then there is a workaround that can be used (probably as a very last resort). You can generate real SQL queries against the OE database, send them out via a .Net ODBC adapter, and transform the results to ABL temp-tables via JSON. It's quite a lot of programming effort but, depending on how long users are waiting for their data, there is the potential for a real large ROI. By using this approach you can even take advantage of server-side joins without having to upgrade to OE 12.
Continue reading...
Continue reading...