2012-04-12 13 views
5

Actualmente estoy almacenando cada vista en la base de datos con IP de usuario, fecha de visualización, etc. Pero el sitio web tiene un gran número de visitas y está aumentando el tiempo de bloqueo de la base de datos y disminuyendo el rendimiento.Mejor estrategia de recuento de vistas

Estaba pensando en guardar los recuentos en un archivo durante 1 hora y luego actualizar la base de datos, pero alguien me dijo que no usamos operaciones de archivos para sitios de carga pesada.

Por favor sugiérame la mejor estrategia para hacer esto.

Nota: No es necesario que cuente las vistas únicas.

+0

Creo que las transacciones pueden ser buenas. – hjpotter92

+0

¿Es esto para fines analíticos? Si es así, quizás desee considerar el uso de un servicio gratuito como Google Analytics o Jetpack para el seguimiento de las visitas. –

+0

¿Debo considerar utilizar el caché de APC para almacenar en caché primero los datos y luego actualizarlos en la base de datos después de algunas vistas ...? –

Respuesta

1

Sus registros de servidores web ya estarán rastreando gran parte de estos datos por usted.

Lo que sugeriría es rotar los registros una vez por hora y luego tener un trabajo programado que produzca las estadísticas agregadas y las almacene en la base de datos.

+0

Parece genial.No tengo mucho conocimiento acerca de los servidores. ¿Pueden decirme dónde puedo encontrar los registros del servidor web? –

+0

¿Qué servidor web está utilizando y qué sistema operativo? –

0

No debería haber ningún problema para mantener y actualizar esta información en MySQL directamente. 3000 visitas por hora significan menos de una consulta por segundo. El uso del motor de almacenamiento InnoDB para esta tabla debería eliminar los problemas de bloqueo. Sin embargo, InnoDB tiene muchas opciones y debe configurarse correctamente para que funcione de manera eficiente; esto es importante.

Sobre la base de sus comentarios creo que la estructura que está buscando sería algo como:

id - page id 
type - period length, could be 'day', 'week', 'month' 
period - date when period starts, could be integer written as YYYYMMDD or YYYYMM 
     - depending on the contents of 'type' field 
count - hit count for a url over given period 

La clave principal sería (type, period, id). También índices en (id, period) y en (type, period, count) para una eficiente:

SELECT * 
FROM ... 
WHERE type='week' 
    and period = 20120409 
ORDER BY count DESC 

Cuando se crea la página, registros de inserción para cada periodo de conteo = 0. Cuando la página se pone en un éxito, ejecutar una simple actualización:

UPDATE table 
SET count = count + 1 
WHERE id = $page_id 
    AND period IN (201204, 20120409) 

Actualizaría los tres registros para las estadísticas de "día", "semana" y "mes".

+0

No estoy almacenando el tipo de vista, sino que estoy calculando la vista por fecha. Ni siquiera la URL como ID es suficiente en mi caso. Pero estoy actualizando la base de datos en cada vista. –

+0

La actualización de esta información en cada vista no debería ser un problema con solo 1 página por segundo. – Mushu

+0

Y si puede usar ID en lugar de URL, entonces la columna url no sería necesaria. Solo 'id' con el valor de la identificación de la página en lugar del incremento automático sería suficiente. – Mushu

0

Ya hay un complemento que hace esto de manera muy efectiva (aunque tendrías que trabajar usando los datos para clasificar publicaciones, etc.): BAW Post Views Count. Almacena todo en postmeta, por lo que es fácil de acceder y mantiene totales diarios y otros en meta entradas separadas. Lo uso en varios sitios, con periodos de 50,000 páginas vistas por día, y no desacelera nada.

Cuestiones relacionadas