Traitement des requetes PHP longues par un serveur mutualisé [Résolu]

[lysandre]

Bonjour,

Je suis sur un hébergement mutualisé 90plan chez OVH et j'aimerais savoir comment un serveur mutualisé gère les requetes PHP qui peuvent durer longtemps (20-30sec). Est-ce que le serveur met à la queue chaque requete provenant d'un même site, et donc si deux utilisateurs font appel à une page du site en même temps, l'un attendra 30 sec le temps d'exécution du php et l'autre 60 secondes le temps d'exécution de la requete du premier utilisateur et de sa requete?
Est-il réaliste de vouloir créer une page dont le temps d'exécution du php soit de 30 sec et qui sera peut-être appelé par un grand nombre de personnes?

[_Mac_]

Je ne sais pas vraiment répondre dans le détail mais je dirais que ça dépend du serveur Web installé et de sa configuration et que donc, avec un serveur Apache, le comportement devrait être le même que pour un serveur mutualisé. Donc, les requêtes concurrentes ne sont pas mises en attente, la page est exécutée plusieurs fois en parallèle.

Le fait que la page mette plusieurs dizaines de secondes à s'exécuter est problématique sur plusieurs plans, en particulier :

• Le nombre de connexions concurrentes du serveur Web peut être vite atteint car les connexions se libèrent lentement. Du coup, là, effectivement, des requêtes peuvent être mises en attente et certaines pourraient ne pas être honorées.
• Timeout d'exécution et de connexion. C'est une sorte de corollaire du premier : un navigateur va peut-être attendre plus de 30 secondes pour avoir sa réponse et donc considérer que le délai max d'attente est atteint. Idem pour le serveur, surtout si il y a beaucoup de charge : le temps d'exécution du script pourrait augmenter (en plus des temps d'attente du point précédent) et générer des timeouts côté serveur et client.
• Ressenti utilisateur : plus l'utilisateur devra attendre une page, plus il aura tendance à dire "ça marche pas" et hop ! il interrompt le chargement de la page et relance la requête, etc. Dans tous les cas, l'utilisateur doit être averti que ça travaille et qu'il faut qu'il patiente, donc mettre en place une page d'attente, et surtout pas laisser une page blanche "frustrante".

Bref, pour les scripts qui peuvent mettre longtemps à s'exécuter, le "mode d'appel synchrone" du Web n'est pas adapter et il est préférable d'envisager une autre solution. Avec 30 secondes, ça me semble encore acceptable comme temps d'attente (mais surtout pas avec une page blanche). Il faudra "bencher" l'application pour mesurer les limites et voir s'il faut envisager un autre mode d'interraction.

[lysandre]

Pour le nombre de connexions concurrentes permises il va falloir que je demandes à mon hébergeur...
Pour le page d'attente, j'avais dans l'idée de diriger l'utilisateur vers une page contenant le message d'attente qui contiendrait un <meta http-equiv="refresh" menant à la page qui met longtemps à s'afficher. Comme ca durant le chargement, la page contenant le message d'attente resterait affichée. Je ne sais pas si c'est comme ca qu'on fait habituellement?

[_Mac_]

Le problème avec cette solution c'est le lancement de la page qui met du temps à se charger. Tu peux essayer mais je ne garantis pas qu'une page blanche ne s'affichera pas le temps du traitement. Sinon, y a la solution Ajax ou iframe cachée qui fait une requête régulièrement sur une page qui indique si le traitement et terminé et renvoie sur la page de résultat le cas échéant.

[lysandre]

Envoyé par _Mac_

Le problème avec cette solution c'est le lancement de la page qui met du temps à se charger. Tu peux essayer mais je ne garantis pas qu'une page blanche ne s'affichera pas le temps du traitement. Sinon, y a la solution Ajax ou iframe cachée qui fait une requête régulièrement sur une page qui indique si le traitement et terminé et renvoie sur la page de résultat le cas échéant.

Ok merci Mac je vais faire des essais.