I don't think we experienced a peak, I only see the requests of less than 5 users (it was during the night, we usually don't have a lot of users at this time).
One component I forgot in this stack is a Nginx instance that takes the role of a gateway using the reverse proxy feature. The request makes NodeJS app ---> Nginx Gateway ---> PHP app. On the Nginx gateway logs, I can see two kind of errors: - The Nginx gateway is unable to connect to the PHP service: "2018/10/16 22:03:45 [error] 7#7: *4276 connect() to [2a00:1450:400c:c04::99]:80 failed (101: Network is unreachable) while connecting to upstream, client: 172.17.0.4, server: , request: "GET /messagings HTTP/1.1", upstream: "http://[2a00:1450:400c:c04::99]:80/messagings", host: "services.maxime.pro" - The Nginx gateway seems to forward a 502 error returned by the PHP service (the error of my first message) GET /find" 502 332 "-" "axios/0.18.0 What's weird for me is how random is this error. It happens a few times every day, but most of my tests are ok - so it's quite hard to reproduce and debug... Here is the app.yaml of the PHP app runtime: php env: flex service: platform runtime_config: document_root: public automatic_scaling: min_num_instances: 1 max_num_instances: 10 cpu_utilization: target_utilization: 0.6 env_variables: PHP_ENV: production readiness_check: path: "/health" check_interval_sec: 5 timeout_sec: 4 failure_threshold: 2 success_threshold: 2 app_start_timeout_sec: 60 I don't know if it's the same issue, but some other threads talk about a routing error for flex environements when min_instances is set to 1 and suggest to set it to 2. We'd rather use a standard environement instead (because of the costs), I don't know if it can fix the issue. Le mercredi 17 octobre 2018 19:32:18 UTC+2, Olu a écrit : > > The "failed_to_connect_to_backend" is similar to "failed_to_pick_backend" > response and this often occurs when the load balancer knows where it wants > to send traffic but cannot successfully route its request or find a healthy > or available instance. Reviewing the instance usage and health checks > <https://cloud.google.com/load-balancing/docs/https/#http_load_balancing>, > might be appropriate to ensure these responses are correlated. > > This error message may also be returned whenever there are a low number > of instances serving your service > <https://issuetracker.google.com/71840041#comment25>. For example, this > error may be returned whenever an unexpected spikes in traffic occur and > there are not enough instances to handle the received requests. In this > type of situations, the load balancer attempts to route your application > requests but it does not have instances to serve those request, hence, it > will produce this "failed_to_connect_to_backend" or > 'failed_to_pick_backend' error. > > Perhaps you can add a screenshot of your app.yaml file of your AppEngine > application, this should display the configurations that apply to your > instance presently, and of course, the number of instances you configured. > -- 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/55f517ed-604e-4ad4-859b-de797dd1e610%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
