Valeurs de délai d'attente HTTP POST sensibles à utiliser lors de l'émission de demandes par programme?

Question

Lors de l'émission par programme des requêtes HTTP POST, quelles valeurs de délai d'attente seraient sensibles?

Dans mon cas, je cherche à définir des valeurs de délai d'attente 'sensibles' lors de la création de requêtes POST en PHP, mais ceci s'applique à n'importe quelle langue.

Je dois pouvoir émettre un ensemble de demandes, chacune à une URL spécifiée par l'utilisateur. Si j'ai besoin de traiter les demandes de manière consécutive plutôt que simultanée, j'aimerais spécifier un délai raisonnable au-delà duquel une demande est réputée avoir expiré. Le code default socket timeout de PHP est de 60 secondes. Cela semble inutilement long à attendre avant de décider qu'une demande ne sera pas complétée. Comme il s'agit de requêtes POST, elles doivent se terminer rapidement. Il n'y a pas de données à extraire et renvoyer comme dans le cas d'une requête GET.

Nous devrions être en mesure d'assumer, la plupart du temps, que l'incapacité d'émettre une réponse à une demande en quelques secondes X signifie que l'hôte est peu susceptible d'émettre une réponse dans un délai raisonnable pour les valeurs de X significativement inférieur à 60.

Les hôtes prennent rarement plus de 60 secondes pour répondre à une demande POST simple. Est-ce qu'ils prennent rarement plus de 10 secondes? 5 secondes? Quelles pourraient être les valeurs sensibles pour X dans la pratique? Les justifications accompagnant les suggestions seraient extrêmement bénéfiques.

Answer 1

Je vous recommande de mettre en place un test, car il y a trop de facteurs impliqués pour donner une valeur qui sera toujours raisonnable.

Une demande POST envoie des données à traiter. Combien de temps avec le traitement prendre? Ce sera spécifique à l'application/aux données.

Où est l'hôte? L'utilisateur fournit l'URL, de sorte que ce sera inconnu. Nous ne pouvons pas savoir quel est le trafic entre votre application et l'hôte. Nous ne pouvons pas connaître la charge du serveur de l'hôte.

Essentiellement, il n'y a pas de délai d'attente sensible universel. Vous devez utiliser votre meilleur jugement en fonction de vos besoins spécifiques. Configurez un test et utilisez-le pour déterminer vos limites.

Answer 2

La plupart des bibliothèques ont un délai de connexion et un délai de lecture. C'est-à-dire le délai d'attente entre la tentative de connexion au serveur distant et le délai d'expiration après l'envoi de la demande, à savoir qu'ils doivent attendre une réponse.

S'il s'agit d'un service Web local, je définirais le délai d'attente de connexion bas, 1 seconde ou moins si votre bibliothèque le prend en charge. Si le service distant auquel vous vous connectez est indisponible, il vaut mieux renvoyer immédiatement une réponse à l'utilisateur que d'autoriser tous vos threads de travail à se bloquer sur ce service distant, provoquant ainsi d'autres erreurs en amont. En ce qui concerne le délai d'attente de lecture, c'est plus compliqué, vous avez besoin qu'il soit faible, pour ne pas épuiser votre pool de travailleurs qui attendent le retour du service distant, mais vous ne le souhaitez pas non plus. bas qu'il ferme la connexion avant de lire une réponse. C'est quelque chose que vous devrez tester, puis suivre en tant que mesure lorsque votre système est en production.