Asp.Net chat de votación del lado del servidor

Question

Helo,

He implementado una aplicación de chat utilizando el cometa. la solicitud se "cuelgue" en el servidor hasta nuevos mensajes arive. Es, entonces, vuelve al cliente con los nuevos mensajes, y se dirige al servidor de nuevo.

Mi problema es:

Con el fin de comprobar si hay nuevos mensajes, sondeo de la base de datos cada 600 ms. Realizo una consulta sencilla ", seleccione ... de mensajes donde messageId> '+ lastMessageId.

Además, con el fin de mantener la presencia, puedo actualizar la base de datos muy (muy) a menudo con cada usuario "LastKeepAliveTime".

El registro de transacciones de SQL Server está creciendo enorme, y, en cierto punto, mi aplicación de chat deja de funcionar.

Los usuarios de chat no son usuarios registrados, que son los usuarios sólo al azar que pueden salir de la página en cualquier momento.

Gracias Yaron

Answer 1

¿Podría utilizar un objeto de caché común para el último mantener la información con vida? Parece que es una pequeña cantidad de información y que podría evitar una gran cantidad de cambios de SQL.

Answer 2

Aquí es cómo mantener el registro de transacciones de conseguir fuera de control: http://support.microsoft. com / kb / 873235

Las opciones en este artículo incluyen:

• Hacer un psiquiatra.
• Cambiar el tamaño del registro.
• Configuración de expansión automática.
• Cambiar el modelo de recuperación.
• Copia de seguridad del archivo de registro con regularidad.

y más.

Como nota al margen, puede ser útil para establecer una lista de usuarios y sus últimas fechas de las actividades que se almacenan como objetos en el estado de la aplicación. Sería más rápido para acceder de esa manera y que podría persistir los valores con menor frecuencia.

Answer 3

El cambio de registro de transacciones modo completo al modo simple debe resolver sus problemas de crecimiento de registro.

Sin embargo, también debo añadir que por lo general es una buena idea para evitar la votación si es posible, ya que no es escalable. Se podría considerar el cambio a un modelo orientado a eventos utilizando Service Broker o SqlDependency. Hay otros enfoques para HTTP abiertas, también.