Latency in Service Callout requesting Google Cloud API - Apigee X

Hi,

I have an api proxy that needs to make a request to Google Cloud Datastore API to retrieve a data stored on it. At the moment this data can not be moved from Datastore although it is planned to do so in the future. I'm observing that the policy has a very large latency. I attach a screenshot to illustrate.

The request to datastore is simply a get by Id two entities. The code of the policy is this:

 

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="SC.GetGroupsAndFellowsFromDs" continueOnError="false">
<Request>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<Set>
<Payload contentType="application/json">
{validateMembershipJsonRequest}
</Payload>
<Verb>POST</Verb>
</Set>
</Request>

<Response>validateMembershipResponse</Response>

<HTTPTargetConnection>
<Authentication>
<GoogleAccessToken>
<Scopes>
<Scope>https://www.googleapis.com/auth/datastore</Scope>
</Scopes>
<LifetimeInSeconds>3600</LifetimeInSeconds>
</GoogleAccessToken>
</Authentication>
<URL>https://datastore.googleapis.com/v1/projects/my-project:lookup</URL>
</HTTPTargetConnection>
</ServiceCallout>

 

 

 

As can be seen the latency is more than 700ms

Captura de pantalla 2022-02-11 a las 11.57.22.png

In this case, the proxy is deployed in europe-west1 and the Datastore is in us-central1. Even if there is an intercontinental crossing, 700ms seems too long to me.

The HTTP request when the target is a Google API goes through public Internet? I understood that no because my subnet peered to Apigee has the "Private Google Access" on.

Can someone help me clarify the reason for this high latency?

Thank you!!

 

 

Solved Solved
0 1 239
1 ACCEPTED SOLUTION

700ms seems too long to me.

That may just be what it takes. The usual optimizations apply - HTTP sessions and TLS handshakes. If you can re-use the connection, that will improve things. Also the usual disclaimers: if you measure ONE message, that will definitely be the most expensive message. It will not take advantage of any connection re-use, a full TLS handshake is required (multiple roundtrips, etc).

The HTTP access from Apigee X to a Google Datastore API does not need to traverse the public network, though it may do so.

The HTTP access from Apigee Edge to a Google datastore API will traverse the public network. But it still may be on Google fiber.

Also, see:

https://docs.apigee.com/api-platform/antipatterns/service-callout-no-target

At the moment this data can not be moved from Datastore although it is planned to do so in the future.

I think the use of Datastore is not the most important factor in determining latency. It's the geography, and the TLS handshake. 

View solution in original post

1 REPLY 1

700ms seems too long to me.

That may just be what it takes. The usual optimizations apply - HTTP sessions and TLS handshakes. If you can re-use the connection, that will improve things. Also the usual disclaimers: if you measure ONE message, that will definitely be the most expensive message. It will not take advantage of any connection re-use, a full TLS handshake is required (multiple roundtrips, etc).

The HTTP access from Apigee X to a Google Datastore API does not need to traverse the public network, though it may do so.

The HTTP access from Apigee Edge to a Google datastore API will traverse the public network. But it still may be on Google fiber.

Also, see:

https://docs.apigee.com/api-platform/antipatterns/service-callout-no-target

At the moment this data can not be moved from Datastore although it is planned to do so in the future.

I think the use of Datastore is not the most important factor in determining latency. It's the geography, and the TLS handshake.