D
dbeavon
Guest
Thanks for double-checking my work. I appreciate knowing that I wasn't crazy in my observations. I think that, while my observations were accurate, it was my original conclusions that were wrong. I now suspect it may be that the duration of the "FOR EACH" operation on the server is what is determining how many network round-trips are performed, not the other way around. (IE. if the operation is taking longer, then by default it schedules more round-trips to return intermediate results to the client.) In the end, the root cause for the higher quantity of network messages was probably related to the extended duration of time that was used for completing the work (ie. operating on ~14000 records vs ~4000, which is roughly 3x more .) I don't think the network traffic in itself was a source of any substantial delays - at least not in any of these tests above. Perhaps if our network was bad *and* the database operation was long-running, then my performance problems would be compounded by all the additional round-trips that would return intermediate results.... ....George, as a suggestion for the future... you may want to include the elapsed ETIME output in your tests - especially if I'm correct in my theory that the duration of work can be the direct cause for a higher number of round-trip messages. The overall lesson here seems to be simply that indexes make ABL code execute quite a lot faster (even when the entire table resides in memory). I was quite a bit shocked to see 3x messages, but I think I understand that the reason for that originates with the performance of the database table . Another lesson learned was that the prefetch* configuration should avoid compounding database performance problems with larger network performance problems.
Continue reading...
Continue reading...