feat: Improved latency for executeStreaminSql calls

[saranshdhingra]

Earlier the encodeMessage was used to convert the PartialResultSet proto to an array. Now, with googleapis/gax-php#554 in GAX, we can provide a way to convert the proto to an array which gets us this huge improvement in the conversion. The improvements are visible specially when the protobuf PECL extension is enabled.

A few tests that I ran:

On my local mac (Protobuf extension enabled):

Test 1:

Load a proto with JSON size ~ 1MB

Time to serialize the proto into an array:
Without this fix: 810 ms
With this fix: 28 ms

Test 2:

Call a SELECT * FROM <table> LIMIT 100 (23 column table) using $database->execute twice. The time recorded is end-to-end, including looping through the results. Please note that, the first query can often be slower due to many network/GRPC related reasons.

Without this fix:
Iteration 1 completed in 110.547951 ms
Iteration 2 completed in 80.933988 ms

With this fix:
Iteration 1 completed in 76.404962 ms
Iteration 2 completed in 57.99326 ms

Test 3:

Call a SELECT * FROM <table> LIMIT 10000 (23 column table) using $database->execute twice. The time recorded is end-to-end, including looping through the results. Please note that, the first query can often be slower due to many network/GRPC related reasons.

Without this fix:
Iteration 1 completed in 4.09 s
Iteration 2 completed in 3.37 s

With this fix:
Iteration 1 completed in 706.560961 ms
Iteration 2 completed in 321.485171 ms

On a high power compute VM (protobuf enabled)

Test 1:

Load a proto with JSON size ~ 1MB

Time to serialize the proto into an array:
Without this fix: 345 ms
With this fix: 42 ms

Test 2:

Call a SELECT * FROM <table> LIMIT 100 (23 column table) using $database->execute twice. The time recorded is end-to-end, including looping through the results. Please note that, the first query can often be slower due to many network/GRPC related reasons.

Without this fix:
Iteration 1 completed in 31 ms
Iteration 2 completed in 26 ms

With this fix:
Iteration 1 completed in 16 ms
Iteration 2 completed in 15 ms

Test 3:

Call a SELECT * FROM <table> LIMIT 10000 (23 column table) using $database->execute twice. The time recorded is end-to-end, including looping through the results. Please note that, the first query can often be slower due to many network/GRPC related reasons.

Without this fix:
Iteration 1 completed in 1.83 s
Iteration 2 completed in 1.78 s

With this fix:
Iteration 1 completed in 204 ms
Iteration 2 completed in 185 ms

It's important to note that in tests 2 and 3, there are many more factors involved like the regions of the application and Spanner instance, internet speed, machine capabilities.

[ser-sergeev]

@saranshdhingra @bshaffer
I think you break the library somehow. I'm not sure how, but 1.76.0 and 1.76.1 doesn't return all rows.
Here is an information.
#7311