Forum: Rails-ES Guardar accesos a un modelo

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-07 19:23
(Received via mailing list)
Hola gente,

Tengo una duda acerca de como mejorar una implementación de un sistema
de banners  que tengo montado, siento que como la cosa crezca un poco
me puede penalizar bastante de la manera que está implementado.

Os cuento los requisitos y como lo tengo hecho y a ver si  alguien se
lo ocurre alguna manera mas elegante-menos_sucia-sencilla de hacerlo.

Tengo que ser capaz de registrar las impresiones y los clicks que
reciben las entradas de un modelo, en este caso el modelo son banner
lo que viene a ser una imagen que aparece por toda la aplicación, para
luego generar unas estadísticas gráficas por horas, dias, meses y años
de los accesos que reciben.

para ello tengo 4 modelos: banner, hit, click, dump_stat .

En banner mantengo el listado de banner, sus permisos de acceso y
demás lógica de negocio necesaria.
En hit y click introduzco una entrada registrando hora, banner_id y
ip, cada vez uno de los banner recibe una impresión o un click
respectivamente.
De dump_stats os cuento luego cuando veáis como está montando el
tinglado.

Pues bien, lo que hago es lo siguiente una vez al dia lanzo una tarea
rake que coge los hits y los clicks del dia, las procesa en un vector
de 24 valores, luego va actualizando los valores vectores mensuales y
anuales, todo esta logica la tengo metida en metodos de click y hit.
Para tener en cuenta los datos de otros dias todos estos arrays los
almaceno en dump_stats Marshalizados para que me sea mas cómodo
recuperarlos a la hora de añadir nuevos datos o a la hora de pintarlo
con gruff.

Bien problemas que yo le encuentro y me gustaría mejorar de esta sucia
implementación:
  Si un dia sale un bug nuevo en la implementación ( que alguno ha
salido ya) y casca ya se descontrola un poco y quedan unos registros
en la tabla sin procesar, pues no procesa nada mas que los del dia, al
estar basado su funcionamiento en la ejecución diaria, debería
conseguir que esto fuera mas flexible.

  De momento funciona bien, pero si mañana la aplicación crece mas, me
va a penalizar bastante la lluvia de insert que le caen a la db cada
vez que imprime unos de los banners, sobre todo cuando se dejan
abiertas X páginas en los clientes y el sistema de banners rotatorio
no para de pedir nuevos banner por ajax.

Me gustaría oir ideas o si os habéis visto en una parecida como lo
implementasteis, insultos o lo que os parezca :-p

Gracias

Saludos
Felipe
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-07 20:57
(Received via mailing list)
2008/10/7 Felipe Talavera Armero <felipe@iniestahoy.com>:

>        Si un dia sale un bug nuevo en la implementación ( que alguno ha
> salido ya) y casca ya se descontrola un poco y quedan unos registros
> en la tabla sin procesar, pues no procesa nada mas que los del dia, al
> estar basado su funcionamiento en la ejecución diaria, debería
> conseguir que esto fuera mas flexible.

Pero tu esos registros los puedes reprocesar no? Los marcas como
procesados o simplemente le dices a tu cron: "calculame de las 00:00
de ayer, a las 00:00 de hoy"? Cuanto tardas a procesar los hits?

Si es muy crítico no perder hits puedes meter un cron semanal para que
recalcule nuevamente los hits y así tienes un doble cálculo. ¿No?

>        De momento funciona bien, pero si mañana la aplicación crece mas, me
> va a penalizar bastante la lluvia de insert que le caen a la db cada
> vez que imprime unos de los banners, sobre todo cuando se dejan
> abiertas X páginas en los clientes y el sistema de banners rotatorio
> no para de pedir nuevos banner por ajax.

¿Has pensado meterlo todo en ficheros de texto plano y procesar eso?
Con eso no saturarias la base de datos, y el cálculo "seria más
ràpido", los resultados despues si que los podrias meter en la base de
datos para hacer los gràficos y tal. No se es una idea.

> Me gustaría oir ideas o si os habéis visto en una parecida como lo
> implementasteis, insultos o lo que os parezca :-p

¿Que estas haciendo? ¿Un AdServer o algo parecido?
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-07 21:11
(Received via mailing list)
Por cierto, ¿cuantos hits por segundo a un anuncio tienes actualmente?
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-07 21:29
(Received via mailing list)
2008/10/7 Francesc Esplugas <francesc.esplugas@gmail.com>:

> Por cierto, ¿cuantos hits por segundo a un anuncio tienes actualmente?

Acabo de hacer una prueba en plan ràpido ... si lo metes en base de
datos.

    - 100K registros en 612,83 segundos

Si lo haces metiendo los datos en un log file, (Logger.new)

    - 100K registros en 11,19 segundos

En fin, que quizas pueda interesarte meterlo en log files, recuerda
que entonces tendras que hacer un rotate de los logs ... etc ...
despues eso lo procesas y ya está. ;)
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-07 22:47
(Received via mailing list)
On Oct 7, 2008, at 8:56 PM, Francesc Esplugas wrote:

> Pero tu esos registros los puedes reprocesar no? Los marcas como
> procesados o simplemente le dices a tu cron: "calculame de las 00:00
> de ayer, a las 00:00 de hoy"? Cuanto tardas a procesar los hits?
>
> Si es muy crítico no perder hits puedes meter un cron semanal para que
> recalcule nuevamente los hits y así tienes un doble cálculo. ¿No?

Pues hago justo eso calcúlame los hits de tal hora a tal hora y punto,
tendré k ver lo del reprocesado para hacerme cargo de los que se
quedan por ahi sueltos, no debería ser un gran problema, aunque cada
vez se complica mas la lógica. Lo que hago es borrar los que proceso,
para no tener tablas de millones de entradas.

> ¿Has pensado meterlo todo en ficheros de texto plano y procesar eso?
> Con eso no saturarias la base de datos, y el cálculo "seria más
> ràpido", los resultados despues si que los podrias meter en la base de
> datos para hacer los gràficos y tal. No se es una idea.


Sip, voy a tener que plantearmelo, ahora mismo la app aguanta bien,
pero si crece mas tendré problemas, tengo unas 8 peticiones/sec a los
anuncios en hora punta, lo de loggear voy a tener k plantearmelo y
jugar con expresiones regulares para el procesamiento, he mirado y por
ejemplo en preparar todas las estadísticas del dia de ayer tardó unos
12 mins, pero vamos el cálculo offline no me afecta si tarda un poco
mas o menos, lo que me interesa es que las gráficas en los
controladores se crean en tiempo real sin necesidad de cachear.

> ¿Que estas haciendo? ¿Un AdServer o algo parecido?


Uhm bueno, es como un pequeño adserver que va integrado en la misma
web, por lo que los usuarios que tienen banners contratados pueden
acceder a sus estadísticas  de como van las campañas.

Estuve buscando un plugin o algo mas enlatado para el cálculo y
procesamiento de los hits y click, pero no he encontrado nada que se
me adaptara.
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2008-10-07 23:21
(Received via mailing list)
2008/10/7 Felipe Talavera Armero <felipe@iniestahoy.com>

> Hola gente,
>
> Tengo una duda acerca de como mejorar una implementación de un sistema
> de banners  que tengo montado, siento que como la cosa crezca un poco
> me puede penalizar bastante de la manera que está implementado.
>


Puede que no te sea de mucha ayuda de forma directa, pero ... gran
presentación de Paul Hammond sobre Flickr Stats, quizás te inspire a
algo

http://www.paulhammond.org/2008/10/flickrstats/


Por cierto, yo he estado buscando recursos sobre la construcción de una
red
de publicidad online, pero parece inexistente. Todo lo que se escribe
sobre
el tema es desde el punto de vista del anunciante, pero no de los
responsables de la red
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-07 23:32
(Received via mailing list)
On Tue, Oct 7, 2008 at 11:21 PM, Manuel González Noriega
<manuel.gonzalez.noriega@gmail.com> wrote:

> Por cierto, yo he estado buscando recursos sobre la construcción de una red
> de publicidad online, pero parece inexistente. Todo lo que se escribe sobre
> el tema es desde el punto de vista del anunciante, pero no de los
> responsables de la red

A los de "The Deck" creo que no les está funcionando nada mal, quizas
en su web expliquen un poco como lo tienen montado.
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2008-10-07 23:57
(Received via mailing list)
2008/10/7 Francesc Esplugas <francesc.esplugas@gmail.com>

>
> A los de "The Deck" creo que no les está funcionando nada mal, quizas
> en su web expliquen un poco como lo tienen montado.
>

Sí, The Deck es el referente de lo que me interesaba. Pero me he
encontrado
que no hay, o yo no he sabido encontrar, nada sobre los factores a
considerar a la hora de construir algo similar, ni en Google, ni en
árboles
muertos. La literatura sobre anuncios online se reduce a 2000 versiones
de
"hazte rico con tu blog"
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-08 00:26
(Received via mailing list)
On Oct 7, 2008, at 11:21 PM, Manuel González Noriega wrote:

> Puede que no te sea de mucha ayuda de forma directa, pero ... gran
> presentación de Paul Hammond sobre Flickr Stats, quizás te inspire a
> algo
>
> http://www.paulhammond.org/2008/10/flickrstats/

uff gran presentación, parece que ellos tenian el mismo problema pero
con muchos ordenes de magnitud mayor y han conseguido salir airosos.
Me ha dado alguna idea de por donde tirar... creo que reforzaré un
poco el código para procesar las entradas perdidas y estudiaré sacar
de db a ficheros el conteo.
39086eb3d9a1437276d07c08ea0c3821?d=identicon&s=25 Guillermo (Guest)
on 2008-10-08 08:11
(Received via mailing list)
2008/10/7 Felipe Talavera Armero <felipe@iniestahoy.com>

> lo que me interesa es que las gráficas en los
> controladores se crean en tiempo real sin necesidad de cachear.
>

Salvo que necesites cosas raras. Google chart.

http://chart.apis.google.com/chart?cht=p3&chd=t:60...

Mira esa url y juega con los parámetros, que en ellos están los datos.
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-08 10:02
(Received via mailing list)
On Oct 8, 2008, at 8:11 AM, Guillermo wrote:

>
> Mira esa url y juega con los parámetros, que en ellos están los datos.
>

Ahora mismo lo tengo implementado y funcionando perfectamente con
gruff pero me dan ganas de reescribirlo al ver algunas gráficas que
tienen los google, sin duda mas potente que gruff, lo único es tener
que depender de ellos siempre, que no me hace demasiada gracia..
This topic is locked and can not be replied to.