You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is beneficial to measure OHTTP-added latency before applying the protocol on a big scale.
To reliably trace the time on each step of the OHTTP pipeline in ideal world it would be needed to use same Precision Time Protocol service on all the actors: client, relay, gateway, target server. But it's quite hard to achieve since all of this is on the different networks and require substantial efforts.
But similar metrics can be implemented WITHOUT PTP servers if to be done on RELAY side with just the execution time provided by the gateway. The idea is simple: on the relay in runtime measure total execution time and request start time. Gateway should add 3 extra custom headers into the response to the gateway (along with encapsulated response): 1 gateway code execution duration; 2. Roundtrip to Target server duration; 3. Target server execution time (returned by target server and not from all endpoints but the completeness here is not needed as these network latencies to one Target endpoint or another are pretty similar to the same server/AWS env).
Having all these values from Relay, Gateway and Target the RELAY can summarise them into quite a comprehensive metrics for added latencies on every step and the network latencies in-between.
The text was updated successfully, but these errors were encountered:
It is beneficial to measure OHTTP-added latency before applying the protocol on a big scale.
To reliably trace the time on each step of the OHTTP pipeline in ideal world it would be needed to use same Precision Time Protocol service on all the actors: client, relay, gateway, target server. But it's quite hard to achieve since all of this is on the different networks and require substantial efforts.
But similar metrics can be implemented WITHOUT PTP servers if to be done on RELAY side with just the execution time provided by the gateway. The idea is simple: on the relay in runtime measure total execution time and request start time. Gateway should add 3 extra custom headers into the response to the gateway (along with encapsulated response): 1 gateway code execution duration; 2. Roundtrip to Target server duration; 3. Target server execution time (returned by target server and not from all endpoints but the completeness here is not needed as these network latencies to one Target endpoint or another are pretty similar to the same server/AWS env).
Having all these values from Relay, Gateway and Target the RELAY can summarise them into quite a comprehensive metrics for added latencies on every step and the network latencies in-between.
The text was updated successfully, but these errors were encountered: