The changes seems to do the trick. We are down to about 1/2 of the original quorum read performance. I did not see any more errors.
More than 3 seconds on the client side is still not acceptable to us. We need the data in Python, but would we be better off going through Java or something else to increase performance? All three seconds are taken up in Thrift itself (fastbinary.decode_binary(self, iprot.trans, (self.__class__, self.thrift_spec))) so I am not sure what other options we have. Thanks for your help.