D
dbeavon
Guest
I went ahead and introduced the prefetch options: -prefetchDelay -prefetchFactor 100 -prefetchNumRecs 1000 Below is the output for the "with index" scenario, and the "without index" scenarios, respectively: │Messages receive: 8 │ │ Messages sent: 7 │ │ Bytes received: 1024 │ │ Bytes sent: 219342 │ │Records received: 0 │ │ Records sent: 3953 │ │Queries received: 7 │ │ Time slices: 3947 │ │Messages receive: 8 │ │ Messages sent: 7 │ │ Bytes received: 1040 │ │ Bytes sent: 219342 │ │Records received: 0 │ │ Records sent: 3953 │ │Queries received: 7 │ │ Time slices: 3985 │ As you can see, they have become essentially the same (whereas previously they indicated a difference in network traffic by a factor of 3). While the network traffic is (finally) the same - regardless of the index - the performance is still quite different. When the index is present the code runs in 40ms, vs 70ms when its not available. So its clear that, in the end, the network activity wasn't the root cause of the performance problems which I was trying to troubleshoot. While it was true that network activity used to be three times higher when an index was not in use, it was probably not the root cause of performance problems since the performance problems persist, despite the equivalent network activity that we see now.
Continue reading...
Continue reading...