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.

Reply via email to