Intensive script PHP à défaut w/ “Le délai d'attente a expiré” erreur / ap_content_length_filter
De l'exécution d'un MySQL intensive script PHP qui est un échec. Apache journal rapporte ceci:
[Wed Jan 13 00:20:10 2010] [error] [client xxx.xx.xxx.xxxx] (70007)
The timeout specified has expired:
ap_content_length_filter: apr_bucket_read() failed,
referer: http://domain.com/script.php
Essayé de mettre set_time_limit(0)
en haut.
Aussi essayé set_time_limit(0)
Ni fixe le délai d'attente.
Est-il un délai spécifique limite je peux en http.conf
(ou ailleurs) pour éviter cela?
OriginalL'auteur Susan | 2010-01-13
Vous devez vous connecter pour publier un commentaire.
J'ai frappé un très semblables mur ainsi avec Apache 2.4.6 et PHP 5.4.23 FPM/FastCGI.
Symptôme:
Peu importe ce que j'ai mis en PHP ou Apache, mon script délai d'attente de 30 secondes et je voudrais voir la suite dans mon journal des Erreurs d'Apache:
Mon VirtualHost:
Agaçants script php:
Le Correctif: c'est une valeur codée en dur dans Apache
mod_proxy_fcgi
OriginalL'auteur
Tout d'abord, ma solution n'est applicable que pour le Serveur Web Apache.
Je suis en train de travailler sur un script conçu pour agir comme un csv télécharger le script pour un rapport contre un très très grand db, et j'ai rencontré ce problème aussi. Ne suis PAS à l'aide de php, mais plutôt que mon script est écrite dans une langue obscure appelée heitml 😉
L'expiration du délai de demande problème ne se produisent dans mon scénario comme ceci:
Et la seule solution sérieuse je ne peut actuellement s'adapter à l'est à l'aide de ce délai config extension ici : mod_reqtimeout. Il permet le réglage de la temporisation params comme par exemple:
10 secondes pour recevoir la demande, y compris les en-têtes et 30 secondes pour recevoir le corps de la requête:
Attendez au moins 10 secondes pour recevoir le corps de la requête. Si le client envoie des données, augmenter le délai d'attente de 1 seconde pour chaque tranche de 1000 octets reçus, avec aucune limite de délai (sauf pour la limite donnée indirectement par LimitRequestBody):
Attendez au moins 10 secondes pour recevoir la demande, y compris les en-têtes. Si le client envoie des données, augmenter le délai d'attente de 1 seconde pour chaque tranche de 500 octets reçus. Mais ne laissez pas plus de 30 secondes de la demande, y compris les en-têtes:
Généralement, un serveur doit disposer d'en-tête et le corps délais d'attente configuré. Si une configuration courante est utilisée pour le http et le https hôtes virtuels, les délais d'attente ne doit pas être trop faible:
Suis encore pour savoir si il y a une meilleure solution offerte par Apache qui ne m'obligent à utiliser ce module (en supposant qu'il n'est pas installé par défaut, même si c'est inclus dans toutes les versions 2.2.15 et plus tard).
OriginalL'auteur nemesisfixx
Je pense que je reçois le même message d'erreur, mise à jour pour une version ultérieure à la version d'Apache (2.4.16):
Je me demandais pourquoi l'augmentation de max_execution_time dans php.ini n'étais pas de travail.
Pour moi, la solution était tout simplement de l'augmentation de la directive Timeout dans httpd.conf
https://httpd.apache.org/docs/2.4/mod/core.html#timeout
(Ou dans
WHM
->Apache Configuration
->Global Configuration
, selon le cas peut être)Ce délai s'applique pour le temps entre les événements d'e /s. Ainsi, même si le script a été sortie de données presque immédiatement, un long retard dans le milieu du script d'exécution a été la cause du délai d'attente.
OriginalL'auteur Tim Smith
Il y a aussi le php max_execution_time directive. Notez que le serveur web paramètres de délai d'expiration peut également limiter votre script:
En fait, cela ressemble à un Apache erreur, il a également des effets des scripts Python. Avez-vous essayé googler-il encore?
OriginalL'auteur leepowers
Il y a une autre valeur de délai ne constitue pas en php mais en serveur apache. Il va de frein script lorsque rien n'est sur la sortie pour la durée spécifiée donc, lorsque vous faites des plus difficiles à travailler en PHP, vous pouvez atteindre cette limite. Juste l'écho de quelque chose de nouveau pour le navigateur (pas de tampons!) ou augmenter apache valeur de délai d'expiration pour une valeur sûre, aussi loin que je me souviens c'est KeepAliveTimeOut apache propriété. Bonne chance 🙂
OriginalL'auteur dmc
J'ai joué un peu avec ces limites de ressource en php.ini pour corriger le problème.
OriginalL'auteur Susan
Il y a un délai d'attente dans l'
php.ini
.request_terminate_timeout = 123s
résolu.OriginalL'auteur Jeff Beck
Remarque: Cette réponse est reproduit in extenso à partir d'un question similaire.
Réponse Originale À Cette Question
J'ai Apache 2.4.6, mais le patch à fixer, il est prévu dans Apache >= 2.4.8.
La clé ici est de commencer votre sortie immédiatement de sorte qu'Apache (mod_proxy_fcgi) pense que la connexion est active.
Par exemple, je suis en utilisant PHP et la base de données de requête pour mon appel AJAX prend > 30 secondes.
Parce que je sais que la réponse sera "Content-Type: application/json", j'ai envoyer l'en-tête immédiatement.
OriginalL'auteur Chris
J'ai essayé toutes les suggestions, mais mon problème était dans la php-fpm configuration. J'ai mis la ligne suivante dans mon php-fpm fichier de configuration:
OriginalL'auteur Floaz