[Gaston_Phone]

Je ne vois vraiment pas pourquoi tu sembles t'acharner avec Wamp...

Tout simplement pour que tu puisses reproduire le problème sur ton micro, y appliquer et tester la solution proposée par Ekozan.

[Frd_C]

Après avoir testé la même opération via CURL et obtenu le même résultat ( ) je viens de contacter le support pour avoir une "confirmation officielle" de la limitation sur les hébergements mutualisés.

Étant développeur et non administrateur, le passage au dédié "juste" pour ça n'est pas une option, on va donc chercher une autre solution :]

En attendant, merci pour les réponses

[Frd_C]

Je ne vois vraiment pas pourquoi tu sembles t'acharner avec Wamp...
Tout fonctionne bien sous Wamp, les délais par défauts peuvent être étendus momentanément via des fonctions PHP prévues à cet effet ( http://se2.php.net/manual/fr/function.ini-set.php , http://se2.php.net/manual/fr/functio...et-timeout.php ... ).

Maintenant, le fait qu'en ligne, l'installation soit en CGI et non en handler, que la version de PHP soit différente et que la notion de mutualité oblige à la limitation de certaines fonctions est quelque chose de tout à fait normal.

Si on met dit que la durée d'expiration d'un flux stream ne peut être modifié (comme l'indique Nowwhat), j'en prends note et cherche une autre voie pour maintenir un service en place et surmonter ma problématique.

[Gaston_Phone]

Il n'y a aucun problème avec Wamp (!!).
La config en local ne comporte pas de spécificités (max_execution_time à 30, default_socket_timeout à 60...) et l'utilisation des fonctions (ini_set, stream_set_timeout...) et contextes permet bien d'étendre les délais.

Cela m'étonnerai très fort.

Dans Wampserver, fichier bin\apache\Apache2.2.11\bin\php.ini :
- max_execution_time = 30
- max_input_time = 30

Dans Mowes portable, fichier php5\php.ini :
- max_execution_time = 30
- max_input_time = 30

Pourquoi cela n'existerait pas dans WAMP ?

Mais ces mêmes méthodes ne semblent pas fonctionner une fois sur le serveur de prod. Les questions sont donc de savoir :
-pourquoi ?
-s'il est possible de faire quelque chose ?
-sinon qu'est-il possible de mettre en place ?

Il s'agit de notions de sécurité et place pour les autres.
Prends un dédié, tu pourras faire comme bon te semblera.

[Nowwhat]

Alors là ....
Intervenir dans php.ini - ou dans certains variables au moment de l'exécution, sur un Mutu est impossible.

Les variables comme "default_socket_timeout" ne peut être modifié par l’utilisateur (client "Mutu") car sinon le concept même d'un Mutu tombera à l'eau.

[Frd_C]

Bonjour.

Je n'ai pas de réponse, mais des indices.

A lire surtout: http://www.google.fr/search?q=site%3...w=1674&bih=895

Il s'agit de plusieurs pages - veuillez lire les pages venant de forum.ovh.com => Mutualisé.

Sache aussi que ce que ton "URL" peut être limité en consultations par heure/jour. Une fois dépassé, le serveur au "URL" te bloque.
C'est déjà vu que Google bloque certains données dès qu'un IP précis réclame la même information plusieurs fois par jour.
Il faut savoir que l'IP des Mutus est partagés parmi des milliers des sites.

T'as regardé ton log "out" ?

Le script (en ligne) et la fonction file_get_contents fonctionne bien tant que le délai d'attente de la réponse du serveur distant ne dépasse pas 60s (valeur par défaut de default_socket_timeout).

Le site distant ne bloque pas les IP ni ne limite à un nombre de requêtes. C'est un prestataire qui nous génère des plans CAO à la volée, selon des besoins spécifiques. La génération de certains formats de fichiers, dépendant d'un moteur fourni par Dassault Systèmes, peut mettre plus de 60s. C'est à ce moment que le timeout sur la connexion par socket survient.

Le problème et qu'en ligne, l'augmentation de la durée de default_socket_timeout ne semble pas effective quand on la demande, alors qu'en local, le changement fonctionne et le timeout ne survient pas. Je cherche donc à augmenter la durée d'une connexion socket.

[Frd_C]

Je n'ai plus de WAMP sur mon micro.
Regarde la doc de WAMP et fais tes réglages pour avoir un time-out de 30 secondes.
Puis reteste ton site en local.

Il n'y a aucun problème avec Wamp (!!).
La config en local ne comporte pas de spécificités (max_execution_time à 30, default_socket_timeout à 60...) et l'utilisation des fonctions (ini_set, stream_set_timeout...) et contextes permet bien d'étendre les délais.

Mais ces mêmes méthodes ne semblent pas fonctionner une fois sur le serveur de prod. Les questions sont donc de savoir :
-pourquoi ?
-s'il est possible de faire quelque chose ?
-sinon qu'est-il possible de mettre en place ?

[Nowwhat]

Bonjour.

Je n'ai pas de réponse, mais des indices.

A lire surtout: http://www.google.fr/search?q=site%3...w=1674&bih=895

Il s'agit de plusieurs pages - veuillez lire les pages venant de forum.ovh.com => Mutualisé.

Sache aussi que ce que ton "URL" peut être limité en consultations par heure/jour. Une fois dépassé, le serveur au "URL" te bloque.
C'est déjà vu que Google bloque certains données dès qu'un IP précis réclame la même information plusieurs fois par jour.
Il faut savoir que l'IP des Mutus est partagés parmi des milliers des sites.

T'as regardé ton log "out" ?

[Gaston_Phone]

Je n'ai plus de WAMP sur mon micro.
Regarde la doc de WAMP et fais tes réglages pour avoir un time-out de 30 secondes.
Puis reteste ton site en local.

[Frd_C]

il n'y a aucun moyen de passé au dessus des 30 secondes réécrit ton script en le divisant par étape de 30s

Sauf que le timeout survient uniquement lors d'une étape précise du script et non en raison d'un temps d’exécution trop long de l'intégralité du script. Pour rappel, c'est la génération, sur un site distant, d'un fichier qui provoque un timeout et non l’exécution global du script.

Dans php.ini de WAMP mets :
max_execution_time = 30
max_input_time = 30

En local, dans Wamp, tout fonctionne bien. Si le fichier disant met 120s à se générer, je n'ai aucun timeout. Le problème survient uniquement en ligne sur l'hébergement mutualisé.

[Gaston_Phone]

Dans php.ini de WAMP mets :
max_execution_time = 30
max_input_time = 30

Et applique la solution proposée par ekozan.

[ekozan]

il n'y a aucun moyen de passé au dessus des 30 secondes réécrit ton script en le divisant par étape de 30s

[Frd_C]

Bonjour,

je rencontre actuellement des problème lors de l'utilisation d'un file_get_contents si le temps nécessaire à la récupération du contenu est supérieur à 60sec. Tout fonctionne sans problème en local (Wamp 5.2.6) mais le problème survient en Mutu (720)

Le script complet étant un peu long , voici le fonctionnement :
- Appel du script via XHR

->Appel via file_get_contents d'un script

-> Génération dynamique d'un fichier (ici, timeout si T>60sec)
-> Génération d'une chaine XML contenant l'URL du fichier généré

-> Parsing du XML
-> Téléchargement automatique du fichier (header dans le browser)

La génération du fichier est plus ou moins longue (entre 3sec et 2min).
Tant que cela reste sous la barre des 30 secondes, tout fonctionne.

Afin d'augmenter la durée d’exécution tout (?) a été essayé :
- set_time_limit(300) : pas utile dans le cas présent mais bon, pour la forme...
- file_get_contents(URL) : par défaut -> timeout
- file_get_contents(URL, false, CONTEXT) : avec en context un array http/timeout renseigné -> idem
- ini_set('default_socket_timeout', 300) : -> timeout idem
- stream_set_timeout(fsockopen(URL), 300); -> timeout idem

Bref, je ne vois pas d'autres solutions pour augmenter le délai et éviter le timeout. Sachant que, comme toujours, ça marche en local mais pas en ligne....

Si quelqu'un a une idée...

Fred