[QL] Measure API Request Latency for PayPal Flows

[jaxdesmarais]

Summary of changes

• Send start_time, end_time, and endpoint to FPTI for tracking API request latency in the PayPal flow
• Add new BTCoreAnalytics enum
• Add new BTAPITimingDelegate for sending start/end timing from BTHTTP to BTAPIClient
• Update UnitTests

Checklist

• [x] Added a changelog entry

Authors

List GitHub usernames for everyone who contributed to this pull request.

• @scannillo @jaxdesmarais

[scannillo]

Based on this diagram from Apple’s docs, maybe requestStart isn’t what we want, but rather fetchStart?

The DNS lookup, TCP & TLS setup aren’t included in requestStart.

[jaxdesmarais]

Based on this diagram from Apple’s docs, maybe requestStart isn’t what we want, but rather fetchStart?

The DNS lookup, TCP & TLS setup aren’t included in requestStart.

Nice find, updated here: https://github.com/braintree/braintree_ios/pull/1292/commits/7ffd8ab6c1a473264a6e4ce9d090dc859b260c99

[scannillo]

One thing came to my mind - once the batching logic is in place, maybe we should just send this analytic event for all API requests (not just PP)? Since our batching is time based and not based on the # of events, I don't think it will have too much impact on consuming too much networking bandwidth.

Do we think those metrics would also be useful to have?

[scannillo]

@jaxdesmarais following up here - we talked IRL about merging this in anyways, even if batching isn't complete. Do we want to run a few comparison tests using OS Signpost to make sure this change isn't adding too much additional time?

Getting actual data for these analytics from real merchant usage will help us a ton

[jaxdesmarais]

@jaxdesmarais following up here - we talked IRL about merging this in anyways, even if batching isn't complete. Do we want to run a few comparison tests using OS Signpost to make sure this change isn't adding too much additional time?

Getting actual data for these analytics from real merchant usage will help us a ton

For sure, I am using branch api-request-latency-signpost for testing. Results are on cellular:

• Production: 1.14s, 628.27ms, 957.79ms, 495.53ms, 395.75ms, 864.03ms, 486.59ms, 482.74ms, 717.69ms, 742.30ms = 678.96 average

Results on main:

• Production: 1.02s, 962.32ms, 571.74ms, 547.22ms, 443.80ms, 610.82ms, 461.21ms, 493.29ms, 432.27ms, 409.00ms = 593.37 average

So it looks like on average this would add 85.59ms of latency without batching. Curious if your results are the same.

[scannillo]

Here are my results. I ran them on WiFi for more consistency b/w trials:

[jaxdesmarais]

Are we okay with that variance on stable vs slightly less stable connections to merge this in/release before batching? I agree the sooner we can get more data on these hops the better.

[jaxdesmarais]

For reference here are my local tests with merging this branch into batch-analytics locally:

• Production wifi: 572.52ms, 319.12ms, 426.20ms, 399.95ms, 320.96ms, 404.85ms, 614.79ms, 439.32ms, 439.06ms, 522.78ms = 449.95 average
• Production cellular: 931.14ms, 540.38ms, 548.63ms, 712.02ms, 769.38ms, 545.93ms, 542.22ms, 654.36ms, 692.68ms, 600.24ms = 653.63 average

[jaxdesmarais]

Discussed with @scannillo irl and removing the "do not merge" tag as even in the worst case our latency is minimally impacted. This will allow us to get additional merchant data on these hops and we will fast follow with batching.