0

I'm running a NodeJS Google App Engine service that retrieves a large file and sends it to a Virtual Private Server hosted on Digital Ocean or AWS. The file is about 5MB and takes up to a minute to send in some cases and often times out. Sending the same file from a client running on on my machine, a VPS, or my teammates computer takes less then 5 seconds. After further investigation I discovered that any outgoing request from a Google App Engine instance caps at about 100-200kps regardless of destination. I have not been able to find any information indicating this is something enforced by google.

Is App Engine Capping it? How do I improve the speeds?

Josh
  • 109
  • 3
  • 1
    Are you performing the request from the same region? Take into consideration that the distance could come into latency – Kevin Quinzel Jul 01 '20 at 20:39
  • @KevinQuinzel Requests are both made and received in us-central. Requests made from my machine are coming from Toronto Area. – Josh Jul 02 '20 at 14:29

1 Answers1

1

By reviewing some resources I'd say that you might be affected by this issue, it seems to happen that the custom domains add significant latency when using App Engine.

I found this article with some useful insights over the RTT behavior between regions/cloud providers, and it looks like the responses as you have pointed should be faster.

  • I appreciate the help @sergiofranco. While this has helped me understand a bit more, I don't think this is the issue as I still have problems when using the app engine without custom domains. – Josh Jul 07 '20 at 14:45
  • 1
    What about if you create a VM on AWS and perform a mtr to googleapis.com in order to review possible network issues. This could be coming into a [Networking issue](https://cloud.google.com/support/docs/best-practice#reporting_a_networking_issue) that is better to address with GCP support. I think this might be happening at the dedicated load balancing that attends App Engine request, since you are using the Fetch library. – sergio franco Jul 07 '20 at 20:46