services - enviar xml a web service c#
Devolución de grandes resultados a través de un servicio web (4)
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 para que este conjunto de datos sea tan grande y el servicio web se puede llamar sincronizado o no sincronizado, pero me pregunto cuáles son las opiniones de las personas sobre lo siguiente:
Si se pierde la conexión, todo el conjunto de resultados tendrá que ser regenerado y enviado de nuevo. ¿Hay alguna manera de que pueda hacer algún tipo de "reanudación" si la conexión se pierde o se restablece?
¿Enviar un conjunto de resultados tan grande incluso apropiado? ¿Sería mejor implementar algún tipo de "paginación" donde el conjunto de resultados se genera y se almacena en el servidor y el cliente puede descargar trozos del conjunto de resultados en cantidades más pequeñas y volver a ensamblar el conjunto en su extremo?
De alguna manera no estoy de acuerdo con el comentario secreto de Geek:
Eso ya está sucediendo para ti, se llama tcp / ip ;-) La reimplantación podría ser exagerada.
Hay ocasiones en las que puede querer hacer esto, pero en realidad solo 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 inserción), o de dividirlo 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 hace una UI más ágil y rápida (desde la perspectiva del usuario), pero debes evaluar si el esfuerzo extra valdrá la pena ... porque no creo que sea una cantidad de trabajo insignificante.
No hay una ley dura contra 5 Mb como resultado del tamaño del conjunto. Más de 400 Mb pueden ser difíciles de enviar .
Obtendrás automáticamente manejadores asincrónicos (ya que estás usando .net)
implementar algún tipo de "paginación" donde el conjunto de resultados se genera y se almacena en el servidor y el cliente puede descargar trozos del conjunto de resultados en cantidades más pequeñas y volver a ensamblar el conjunto en su extremo
Eso ya está sucediendo para ti, se llama tcp / ip ;-) La reimplantación podría ser exagerada.
Similar --
todo el conjunto de resultados tendrá que ser regenerado y enviado de nuevo
Si se trata de MS-SQL, por ejemplo, que está generando la mayor parte del conjunto de resultados, entonces al volver a generarlo se aprovechará algo de la caché implícita en SQL Server y las siguientes generaciones serán más rápidas.
Hasta cierto punto, puede salirse con la suya sin preocuparse por estos problemas, hasta que surgen como problemas ''reales'', porque la (s) plataforma (s) que está utilizando se ocupan de muchos de los cuellos de botella de rendimiento para usted.
Por lo tanto, parece que le interesaría 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 la tienda de respaldo es el servidor sql (o incluso mysql) ya que se ha integrado en el soporte para la numeración de filas.
A pesar de esto, debe poder evitar hacer cualquier gestión de sesiones en el servidor, evitar cualquier almacenamiento en caché explícito del conjunto de resultados, y simplemente confiar en el almacenamiento en caché de la tienda de respaldo para mantener su vida simple.
He visto los tres enfoques, paginado , almacenar y recuperar , y empuje masivo .
Creo que la solución a su problema depende en cierta medida de por qué su conjunto de resultados es tan grande y cómo se genera. ¿Sus resultados crecen con el tiempo? ¿Se calculan todos de una vez y luego se presionan? ¿Desea transmitirlos nuevamente tan pronto como los tenga?
Enfoque de paginación
En mi experiencia, usar un enfoque de búsqueda es apropiado cuando el cliente necesita acceso rápido a fragmentos de tamaño razonable del conjunto de resultados similar a las páginas en los resultados de búsqueda. Las consideraciones aquí son el estado de ánimo 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 crece en tamaño a medida que se procesa la consulta. Los problemas 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
El enfoque de empuje masivo es casi seguro defectuoso. Incluso si el cliente necesita toda la información y necesita ser empujada en un conjunto de resultados monolíticos, recomendaría adoptar el enfoque de WS-ReliableMessaging (ya sea directamente oa través de su propia versión simplificada) y fragmentar sus resultados. Al hacer esto,
- asegúrese de que las piezas lleguen al cliente
- puede descartar el fragmento tan pronto como reciba un recibo del cliente
- puede reducir los posibles problemas con el consumo de memoria de tener que retener 5MB de XML, DOM o lo que sea en la memoria (suponiendo que no está procesando los resultados de forma continua) en el servidor y en el lado del cliente.
Sin embargo, como han dicho otros, no haga nada hasta que sepa cuál es el tamaño del conjunto de resultados, cómo se genera y el rendimiento general como problemas reales.