¿Cuál es la mejor manera de implementar el contador de vista de página como los que tienen aquí en el sitio donde cada pregunta tiene un contador de "Vistas"?Contador de vista de página como en StackOverFlow
Teniendo en cuenta los problemas de rendimiento y escalabilidad.
El contador optimicé funciona así:
UPDATE page_views SET counter = counter + 1 WHERE page_id = x
if (affected_rows == 0) {
INSERT INTO page_views (page_id, counter) VALUES (x, 1)
}
Esta forma de ejecutar 2 consulta para el primer punto de vista, las otras vistas requieren sólo 1 consulta.
Una forma eficiente puede ser: Almacene sus contadores en el objeto Aplicación, puede continuar en el archivo/DB periódicamente y al cerrar la aplicación.
Puede implementar un IHttpHandler para hacerlo.
Soy un fanático del estilo de implementación de @ Guillaume. Utilizo un controlador GIF transparente y colas en memoria para agrupar conjuntos de cambios que luego se limpian periódicamente utilizando un subproceso separado creado en global.asax.
El controlador implementa IHttpHandler, procesa los parámetros de solicitud, p. ID de página, idioma, etc., actualiza la cola, luego response.writes el GIF transparente.
Moviendo cambios persistentes en un hilo separado de la facilidad de la solicitud también se ocupa mucho mejor con posibles problemas de serialización de la ejecución de múltiples servidores, etc.
Por supuesto, usted podría pagar a alguien para hacer el trabajo también, por ejemplo, con gifs transparentes.
Para mí la mejor manera es tener un campo en la tabla de preguntas y actualizarlo cuando se accede a la pregunta
UPDATE Questions SET views = views + 1 WHERE QuestionID = x
objeto Aplicación: OMI no es escalable ya que el puede terminar con una gran cantidad de consumo de memoria como más preguntas son accedidas
mesa PAGE_VIEWS: no es necesario, usted tiene que hacer una costosa unirse después
@Eduardo es práctico, incluso con páginas de 10 m. - solo se habla de 10 m como máximo - Creo que quemo 50 MB abriendo el CLR;) La memoria es barata - la serialización no lo es. – stephbu
He hecho dos observaciones sobre el mostrador vistas stackoverflow:
Hay un elemento link en la cabecera que se encarga de activación la actualización del recuento. Para esta pregunta, el marcado se ve así:
<link href="https://stackoverflow.com/questions/246919/increment-view-count" type="text/css" rel="stylesheet" />
Imagino que podría presionar esa url para actualizar el conteo de visitas sin siquiera ver la página, pero no lo he intentado.
Tuve un uservoice ticket, donde la respuesta de Jeff indicó que las vistas no se incrementan desde la misma ip dos veces seguidas.
Gracias por la observación :) – TimLeung
fyi para aquellos que lean esto más tarde - Estoy bastante seguro de que han cambiado esto desde la publicación original. –
parece una buena idea: mantenga el contador en un recurso almacenable en caché, para que solo se incremente la primera vez que se "carga" el recurso. Beats cookies & sessions para simplificar. – tucuxi
En lugar de hacer una llamada de base de datos cada vez que la base de datos es golpeado, me incrementar un contador utilizando un objeto de caché y dependiendo del número de visitas que llegue a su sitio todos los días usted tiene enviar la página golpea a la base de datos cada centésimo golpe al sitio. Esto es más rápido que la actualización de la base de datos en cada golpe.
Otra solución es analizar el archivo de registro de IIS y actualizar visitas cada 30 minutos a través de un servicio de Windows. Esto es lo que he implementado y funciona de maravilla.
Uno de los desafíos aquí es a) la posibilidad de serialización ob) una condición de carrera: depende del nivel de aislamiento de la transacción. – stephbu
Correcto, una de las preocupaciones que tenemos es posiblemente una condición de carrera. ¿Debería hacerse esto de manera asíncrona? – TimLeung
@stephbu: para su b) es más una condición de carrera no crítica porque el aumento de +1 no cambia si una consulta se realiza al mismo tiempo ... +1 +1 o +1 +1 igual siempre +2. –