Geographical location of translation endpoints

[Conal Loughrey]

Hi all,

Does anyone know the geographical locations of the Google translation endpoints? I'm creating a global service with multiple data centres. Currently translation requests from the South American data centre are being routed to the Mountain View endpoint, 216.58.216.170, even though the Georgia endpoint, 172.217.15.74, has a lower latency. To workaround this I will be forcing the South American traffic to route to Georgia.

In order to preempt any similar issues elsewhere it would be good to know where the Google translation endpoints are located.

It would also be great to know if there are plans to create an endpoint in South America.

Many thanks,

Conal

Conal Loughrey      

VP Engineering

Aiqudo

M: +44 (0) 7766 226 906

T: +44 (0) 2890 409 998

[Digil (Google Cloud Platform Support)]

Hello Conal,

Kindly go through the responses provided below, for your various concerns over Cloud Endpoint:-

1. Geographical Location of Google Cloud Endpoint

           As of now, the location of this service is available globally around the world. This service is not binded towards a specific location. You can check the details of various ‘GCP resources global availability’ by referring the help center article on Cloud Locations.

2. Why the request always routed to Mountain view location?

Most of the external Geo IP services are depending upon the SWIP database. And for this reason, most of the Google’s IPs are SWIP’ed to the Mountain View, CA. due to this, even for a GCP resource which is created outside (in your case South America Region) the US shows its IP location as in the US. However, your resource’s actual hardware facility will be located in the region you have selected. You can also go through this Google discussion thread which will give you more comments on a similar concern.

3. Plan to create an endpoint in South America.

As I said in my first answer, this resource is globally available. You can check the infrastructure map where it shows the ‘Edge Points of Presence (PoPs)’, which covers over 90 internet exchanges(includes South America region) and over 100 interconnection facilities around the world.

[Conal Loughrey]

Many thanks for the info Dijil.

I read the other resources you pointed to and I understand what you are saying about the geolocation and IP not necessarily being a good indication of physical location of an endpoint.

I will therefore switch to discussing the latencies I am seeing.

I am running services in a Sao Paulo Brazil data centre. These services make requests to the GCP translation endpoint https://translation.googleapis.com/language/translate/v2

If I make a series of requests (10 non-concurrent requests) to this endpoint I see an average time of 978 ms.

I have created AWS API Gateways in US-EAST and US-WEST that proxy requests to https://translation.googleapis.com/language/translate/v2

The average response time I see for the US-WEST Gateway is 887 ms and for the US-EAST Gateway is 312 ms. Therefore it is faster for me to proxy requests from Sao Paulo via the AWS API Gateway in US-EAST than it is to call the GCP translation endpoint directly.

I looked further into the data and I can see the average connect time to the GCP endpoint is 17ms, the equivalent time to the US-EAST Gateway is 7ms. 

Every time I run the rest I observe lower connection times and lower overall response time when sending requests to the US-EAST Gateway.

Am I doing something wrong here? Based on the information you provided I would expect a direct to the GCP endpoint in Sao Paulo to be faster than a proxy via US-EAST.

Should I be doing something different to get the lowest response times directly from GCP translation?

Many thanks,

Conal

[Digil (Google Cloud Platform Support)]

It looks like the issue reported about the latency on the cloud translation endpoints need a detailed investigation on your project. For that, I would suggest you to open a 'GCP private issue' using the  issue-tracker link. 

While opening the report, make sure that you have included your affected project number and a detailed description of the concern with the test report you have done for this latency.