Devolver grandes resultados a través de un servicio web

Question

Estoy trabajando en un servicio web en este momento y existe la posibilidad de que los resultados devueltos sean bastante grandes (> 5 MB).

Es perfectamente válido que este conjunto de datos sea tan grande y que el servicio web pueda llamarse sincronizado o asíncrono, pero me pregunto qué piensa la gente sobre lo siguiente:

1. Si la conexión se pierde, todo el conjunto de resultados tendrá que ser regenerado y enviado nuevamente.¿Hay alguna forma de hacer algún tipo de "reanudar" si la conexión se pierde o se reinicia?

2. ¿Es apropiado enviar un conjunto de resultados tan grande?¿Sería mejor implementar algún tipo de "paginación" donde el conjunto de resultados se genera y almacena en el servidor y el cliente puede luego descargar fragmentos del conjunto de resultados en cantidades más pequeñas y volver a ensamblar el conjunto al final?

Answer 1

He visto los tres enfoques, paginado, almacenar y recuperar, y empujón masivo.

Creo que la solución a su problema depende hasta cierto punto de por qué su conjunto de resultados es tan grande y cómo se genera.¿Sus resultados crecen con el tiempo? ¿Se calculan todos a la vez y luego se envían? ¿Quiere transmitirlos tan pronto como los tenga?

Enfoque de paginación

En mi experiencia, utilizar un enfoque de paginación es apropiado cuando el cliente necesita acceso rápido a fragmentos de tamaño razonable del conjunto de resultados similares a las páginas de los resultados de búsqueda.Las consideraciones aquí son la charla general de su protocolo, el almacenamiento en caché de todo el conjunto de resultados entre las solicitudes de la página del cliente y/o el tiempo de procesamiento que lleva generar una página de resultados.

Almacenar y recuperar

Almacenar y recuperar es útil cuando los resultados no son de acceso aleatorio y el conjunto de resultados aumenta de tamaño a medida que se procesa la consulta.Las cuestiones a considerar aquí son la complejidad para los clientes y si puede proporcionar al usuario resultados parciales o si necesita calcular todos los resultados antes de devolver algo al cliente (piense en ordenar los resultados de los motores de búsqueda distribuidos).

Empuje masivo

Es casi seguro que el enfoque de impulso masivo es defectuoso.Incluso si el cliente necesita toda la información y debe incluirse en un conjunto de resultados monolítico, recomendaría adoptar el enfoque de WS-ReliableMessaging (ya sea directamente o mediante su propia versión simplificada) y fragmentando sus resultados.Al hacer esto usted

1. Asegurar que las piezas lleguen al cliente.
2. Puede descartar el trozo tan pronto como reciba un recibo del cliente.
3. puede reducir los posibles problemas con el consumo de memoria al tener que retener 5 MB de XML, DOM o lo que sea en la memoria (suponiendo que no esté procesando los resultados en forma de transmisión) en el lado del servidor y del cliente.

Sin embargo, como han dicho otros, no haga nada hasta que sepa que el tamaño del conjunto de resultados, cómo se genera y el rendimiento general son problemas reales.

Answer 2

No existe ninguna ley estricta contra los 5 Mb como tamaño de conjunto de resultados.Más de 400 Mb pueden ser difícil de enviar.

Obtendrá automáticamente controladores asíncronos (ya que está usando .net)

Implemente algún tipo de "paginación" donde se genera y almacena el conjunto de resultados en el servidor y el cliente puede descargar fragmentos de los resultados en cantidades más pequeñas y volver a ensamblar el conjunto de conjunto.

Eso ya le está sucediendo a usted: se llama tcp/ip ;-) Reimplementar eso podría ser excesivo.

Similarmente --

El conjunto de resultados completo tendrá que ser regenerado y enviado nuevamente

Si es MS-SQL, por ejemplo, el que genera la mayor parte del conjunto de resultados, volver a generarlo aprovechará parte del almacenamiento en caché implícito en SQL Server y las generaciones posteriores serán más rápidas.

Hasta cierto punto, puede salirse con la suya sin preocuparse por estos problemas, hasta que surjan como problemas "reales", porque las plataformas que está utilizando se encargan de muchos de los cuellos de botella de rendimiento por usted.

Answer 3

Estoy algo en desacuerdo con el comentario de secretGeek:

Eso ya le está sucediendo a usted: se llama tcp/ip ;-) Reimplementar eso podría ser excesivo.

Hay ocasiones en las que es posible que quieras hacer precisamente esto, pero en realidad sólo desde la perspectiva de la interfaz de usuario.Si implementa alguna forma de transmitir los datos al cliente (a través de algo así como un mecanismo de pushlets) o dividirlos en páginas como sugiere, puede cargar un subconjunto realmente pequeño en el cliente y luego construir lentamente la interfaz de usuario con la cantidad total de datos.

Esto crea una interfaz de usuario más ágil y rápida (desde la perspectiva del usuario), pero hay que evaluar si el esfuerzo extra valdrá la pena...porque no creo que sea una cantidad de trabajo insignificante.

Answer 4

Entonces parece que estaría interesado en una solución que agregue el parámetro 'número de registro inicial' y 'número de registro final' a su método web.(o 'número de página' y 'resultados por página')

Esto no debería ser demasiado difícil si el almacén de respaldo es el servidor SQL (o incluso MySQL), ya que tienen soporte integrado para la numeración de filas.

A pesar de esto, debería poder evitar realizar cualquier gestión de sesión en el servidor, evitar cualquier almacenamiento en caché explícito del conjunto de resultados y simplemente confiar en el almacenamiento en caché del almacén de respaldo para simplificar su vida.