D
dbeavon
Guest
>> just needs to make the network faster... The limitation is about the network, but there is some complexity to it even so. Our network easily does 500 Mbps or 100,000 packets per second. But that doesn't translate directly into faster "client-server" code. From what I can tell, the limitation is primarily in the OpenEdge implementation of client-server. The implementation will frequently slow us down to 2-3,000 records per second. The reason for the slowness is partly due to how "chatty" client/server can be (coordinating a lot of small units-of-work between client and server). And I've found that there is also an artificial CPU delay/bottleneck within the database servers - probably based on the way that it allocates CPU by time slice. If you watch cpu in glance, will often seen _mproapsv get capped out at a predictable, and premature limit (only 9% of a core) even though there is lots of outstanding work that is waiting to be done. ... and the other machine resources like disk and memory and network still have *plenty* of capacity (both on the client side and the server side). As Tom mentioned the trick is to use sets of records (FOR-EACH-NO-LOCK). That will pull 10's of thousands of records per second from the database over a client-server connection. This is better than doing individual finds, and is one of the *ONLY* tricks we have available. It allows client-server to perform as well as shared-memory. Which brings us to cache. This is yet another thing which could level the playing field. A local cache would allow us to instantly retrieve 10's of thousands of records directly from local storage. And we would then be able to create solutions that are just as fast on "client-server" as they are in "shared-memory". Detaching and re-attaching temp-tables is just one (ABL -centered) idea. But truthfully I'd prefer a solution based on SQLite, as long as it was easy to interoperate with it from ABL.
Continue reading...
Continue reading...