Mejores prácticas para los tiempos de espera del servicio web

Question

¿Hay algún artículo/libro que defina los límites de diseño límite superior para los tiempos de espera de WS? ¿Excede el tiempo de espera en el servidor o recomienda los tiempos de espera específicos del cliente también?

¿Hay una mejor práctica común, como "Nunca diseñar WS que puede durar más de 60 segundos, use un patrón de señal asíncrona"

Estoy interesado en saber lo que haces o su opinión también.

Answer 1

Esta pregunta, y los que hay enlaces en respuestas a ella, podría ayudar: Is there some industry standard for unacceptable webapp response time?

Algo tangenciales a su pregunta (no hay intervalos de tiempo, lo siento), pero sospecho útil para su trabajo: Un común el acercamiento a los tiempos muertos es equilibrarlos con temporizadores de "retroceso".
Funciona de la siguiente manera: La primera vez que un servicio expira, no se preocupe. La segunda vez en una fila un servicio expira, no se moleste en llamarlo por N segundos. La tercera vez consecutiva que un servicio expira, no la llame durante N + 1 segundo. Luego N + 2, N + 3, N + 5, N + 8, etc., hasta llegar al límite máximo M.

El contador de tiempo de espera se restablece cuando obtiene una respuesta válida.

Estoy usando una secuencia de Fibbonacci para aumentar el período de "retroceso" aquí, pero por supuesto puede usar cualquier otra función adecuada; el punto es que si el servicio que está tratando lo sincroniza ". la creencia "en ella se hace cada vez más pequeña, por lo que gastas menos recursos tratando de llegar a ella, y tocas la puerta más raramente. Esto podría ayudar al servicio en el otro extremo, que simplemente podría estar sobrecargado y volver a solicitar solo empeora las cosas, y aumentará el tiempo de respuesta, ya que no esperará un servicio que probablemente no responda.

Answer 2

Tome la cantidad de datos que está transfiriendo a través de su servicio web y vea cuánto tiempo lleva el proceso.

Agregue 60 segundos a ese número y pruébelo.

Si logras que expire el tiempo con una buena conexión, agrega 30 segundos más.

enjuague y repita.

Answer 3

Generalmente tomamos el tiempo de respuesta esperado para ese servicio web (como se documenta en nuestra especificación de interfaz) y le agregamos 30 segundos.

Luego supervisamos los registros durante UAT para ver si hay algún patrón (por ejemplo, llamadas DB específicas que tarden mucho) y lo modificamos según corresponda.

Answer 4

Este material de más de 30 segundos de tiempo de espera es un consejo ridículo, IMO. Sus tiempos de espera deben ser de aproximadamente 3 segundos. Sí. Tres. El número después de las dos y antes de las cuatro. Si está creando una aplicación basada en SOA, DEFINITIVAMENTE 3 segundos o menos.

Piénselo ... el usuario de su aplicación espera un tiempo de respuesta TOTAL de aproximadamente cinco segundos o menos (preferiblemente alrededor de tres). Si CADA LLAMADA DE SERVICIO INDIVIDUAL tarda más de un par de * milisegundos * en regresar, se le aplicará una manguera. Esperar más de 30 segundos para que un servicio regrese es una eternidad. El usuario nunca esperará tanto tiempo.Además, si sabe que se supone que deben regresar en el rango de un segundo segundo, ¿qué sentido tiene esperar o más segundos para señalar una condición de error; no funcionará mágicamente donde no lo hizo hace 28 segundos. Si su aplicación tiene cambios bruscos en el tiempo de respuesta promedio de menos de un segundo a más de 30 segundos, algo se diseñó incorrectamente. Puede pensar en algún almacenamiento en caché o algo así.