Hi Jordan, thank you for your detailed response. Node.js is a single threaded runtime, this means that your code must be properly > coded to take full advantage of Node.js's event loop > <https://blog.risingstack.com/node-hero-async-programming-in-node-js/> in > order to be asynchronous. >
We understand the concepts of single-threaded runtime, and we also thought that our code was not correctly structured to take advantage of Node.js's asynchronous capabilities, and so for some reason we were blocking the event loop causing the application to be busy and not responsive to other incoming requests. This is actually why we have deployed an *hello-world* test in the first place, consisting of one single GET requests handler responding "hello-world" (actually taken from the GAE's examples). To out great surprise, though, we experienced the same issue there, and that's why we are even more confused. Note that you should always perform exponential backoff-retry > <https://cloud.google.com/storage/docs/exponential-backoff> on the > client-side (aka you proxy service) in the case that your backend service > becomes too busy and times out. > Absolutely, and in fact we wouldn't have missing packets with retries, but since we are still into preliminary tests, we want to reduce the retransmissions as much as possible and only when the backend is really overloaded (which is not our case, if you look at the plots I attached a couple of messages ago). On Wednesday, October 11, 2017 at 8:37:19 PM UTC+2, Jordan (Cloud Platform Support) wrote: > > So just for completeness and clarity, the error you are seeing on your > backend service "upstream prematurely closed connection while reading > response header from upstream" strictly means that the nginx proxy on that > specific instance of your backend service fails to contact the webserver > (aka your app) in that instance (it is all localized to a specific > instance). > > Normally these often occur due to nginx's health checks failing, but this > can also just happen when nginx does its normal job of proxying incoming > requests to your application. Essentially, the connection between nginx and > your application closes due to your application not responding to it, or > your application completely stops listening to nginx (it listens on port > 8080 > <https://cloud.google.com/appengine/docs/flexible/nodejs/runtime#application_startup> > > as seen in the error). > > Therefore, the issue all comes down to your application code and the > Node.js runtime. Node.js is a single threaded runtime, this means that your > code must be properly coded to take full advantage of Node.js's event loop > <https://blog.risingstack.com/node-hero-async-programming-in-node-js/> in > order to be asynchronous. By having async code, you are allowing concurrent > requests to be executed, which in turn allows your application to always > listen and respond to nginx. Once your application becomes asynchronous, it > is able to properly live and scale in the cloud. > > Note that you should always perform exponential backoff-retry > <https://cloud.google.com/storage/docs/exponential-backoff> on the > client-side (aka you proxy service) in the case that your backend service > becomes too busy and times out. This way, even if you see 5xx responses, > your client should always eventually succeed (once your backend has > recovered). > > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/5622bf06-d350-4fb4-9d25-f130f10b7046%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
