You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--listen-queue=10 # fails if there are more than 10 processes waiting in the fpm queue
In this case, pod should be scaleUp, rather than reset?
--accepted-conn=5000 # fails after fpm has served more than 5k requests, this will force the pod to reset, use with caution
In this case, pod don't have to reset., Why do you configure it this way?
So how do you configure it in production?
The text was updated successfully, but these errors were encountered:
My confusion here is, shouldn't the --listen-queue option be on the readinessProbe? You don't want the pod to be killed, but you want to wait for it to finish off the queue before it getting new requests to handle.
Completely agree with @beschoenen - my understanding that those probes in the examples should be swapped:
livenessProbe - php-fpm-healthcheck # a simple ping since this means it's ready to handle traffic
readinessProbe - --listen-queue=10 # fails if there are more than 10 processes waiting in the fpm queue - we want to wait until the queue reduces before sending more traffic to the pod
https://github.com/renatomefi/php-fpm-healthcheck#livenessprobe
--listen-queue=10 # fails if there are more than 10 processes waiting in the fpm queue
In this case, pod should be scaleUp, rather than reset?
--accepted-conn=5000 # fails after fpm has served more than 5k requests, this will force the pod to reset, use with caution
In this case, pod don't have to reset., Why do you configure it this way?
So how do you configure it in production?
The text was updated successfully, but these errors were encountered: