G
George Potemkin
Guest
Artur, Do you agree that the issue is a round trip time (RTT) rather than network bandwidth in common? SQL databases are much less affected by the issue because they operate with the set of data and they send data over network in large messages. Progress does the same with FOR EACH NO-LOCK queries and they are almost not affected by the issue as we can see from your Progress tests. Connection (without the -cache) to Progress database is affected because a session reads the most of metaschema records with SHARE-LOCK which means one record per network message. In your case a connection with the -cache is 3 times faster. It reads 100 times less metaschema records and uses SHARE-LOCK only 3 times. I would expect that a connection with the -cache would be much faster. In your Progress tests 'FOR EACH SHARE-LOCK' is much slower than 'FOR EACH NO-LOCK NO-PREFETCH'. SHARE-LOCK does add the overheads but it's only 9% on CentOS 6 (1786.0 vs. 1637.6) and 4 times on CentOS 7 (26250.2 vs 6426.9). When we use the queries with SHARE-LOCK a remote client server received twice more messages from its client than when we use NO-LOCK NO-PREFETCH. The number of network messages sent by a server to a client is the same in both cases. I guess CentOS 7 has an asymmetrical issue with RTT. Round trip time seems to depend from a direction. Does iperf3 reuslts depend from where you run it? Can you repeat Progress tests while the location of client and sports2000 db is reversed?
Continue reading...
Continue reading...