Desafortunadamente, cuando se trabaja con grandes conjuntos de datos, siempre llevará tiempo serializar y deserializar la estructura. DataTable Los correos electrónicos en particular son objetos bastante complejos, ya que tienen filas y columnas que a menudo tienen muchos metadatos adjuntos, incluso cuando parece una tabla básica.
DataTable vs List<POCO> :
Considere si realmente necesita serializar como un DataTable . ¿Podría crear un POCO más simple y serializar un List<YourRecord> ? En otras palabras, si no necesita atributos adicionales en campos y columnas y puede serializar a un formato más simple, es probable que sea más rápido y más eficiente en el espacio en el caché; y luego restaurar a una DataTable si es necesario.
Otra opción es dividir la DataTable en conjuntos más pequeños, que usted serializa y almacena en partes más pequeñas. Puede encontrar esto más eficaz. Debería poder comparar esto.
Punto de referencia:
En última instancia, su caché de Redis debería ser una mejora con respecto al tiempo necesario para volver a consultar la fuente de datos. Usas el término takes too much time , pero si toma 2 segundos para obtener desde el caché frente a 8 segundos para consultar la fuente de datos, entonces eso es un impulso significativo. Pero la única forma de estar seguro es mediante la evaluación comparativa.
-
Configure su entorno para que solo ejecute las herramientas necesarias. No realice otras tareas mientras ejecuta los puntos de referencia, para no introducir ningún sesgo.
-
Registre el tiempo que lleva serializar una
DataTable. Realiza esta acción muchas veces y media.var start = DateTime.Now; // Serialize var duration = DateTime.Now - start; -
Experimente con diferentes tamaños de
DataTables y vea si encuentra un tiempo aceptable. -
Pruebe con una biblioteca de serialización diferente, como JSON.NET. Si bien es bueno mantener todo ServiceStack, esto puede ayudarlo a determinar si es una deficiencia de ServiceStack.Text o simplemente un problema con el gran conjunto de datos.
-
Repita el proceso de deserialización.
Memoria:
Si está trabajando con grandes conjuntos de datos, ¿tanto su aplicación como el caché tienen suficiente memoria? La memoria de su aplicación podría ser un cuello de botella; Debe observar el monitor de actividad de su sistema mientras realiza las operaciones y asegurarse de que no se esté quedando sin memoria y que su sistema realice la paginación. Si encuentra que esto sucede, considere aumentar la RAM o dividir DataTable en conjuntos de datos más pequeños como se mencionó anteriormente.
Latencia:
Si se está conectando a un servidor Redis a través de una red y no en la misma máquina, ¿ha verificado la latencia de la red? Es posible que desee hacer ping entre su servidor de aplicaciones y el servidor de caché y asegurarse de que realmente tiene un ping bajo. Particularmente si encuentra que el almacenamiento en caché de objetos simples es lento.
¿Redis?
Si encuentra que no hay forma de mejorar el tiempo de almacenamiento en caché y restauración, entonces tal vez usar Redis no sea una buena opción. Quizás usando una static DataTable dentro de la memoria de la aplicación sería más adecuado. En otras palabras, manteniendo el caché en la memoria de la aplicación y luego no hay que preocuparse por la serialización y la deserialización. Por supuesto, es posible que deba tener cuidado al asegurarse de tener suficiente memoria disponible para su aplicación para hacer esto. Sin embargo, me sorprendería si tuvieras que elegir esta opción .
Resumen:
Sin ver su conjunto de datos o el conocimiento del servicio que está creando, en última instancia, es solo un consejo genérico sobre cómo reducir mejor la causa de su problema. El consejo clave es no usar una DataTable si una estructura más simple es suficiente, y compare cada una de las operaciones para determinar los cuellos de botella.
Espero que esto ayude.
