¿Alguien conoce un ad server escrito con Rails?
U alguna opción que se integre bien conun proyecto Rails. OpenX en PHP
es el primer candidato, pero es quizas algo complejo para nuestro
proyecto.
Saludos,
Si, a mi tb me gustarÃa saber si existe algo parecido a Open X pero para
ruby.
El 14 de octubre de 2008 11:20, Juan m. Blasco <
[email protected]> escribió:
Nunca lo use, pero es cuestion de investigarlo.
Hola Juan,
No conozco ninguno pero en un principio no parece el mejor proyecto
para hacer, al menos completo, usando Rails.
Sí podrías hacer la aplicación de gestión pero a la hora de servir los
avisos te recomendaría algo de más bajo nivel que Ruby y Rails.
Podría ser PHP o un módulo en C (si tienes alguien cerca que pueda
mantener el código). Si fuera posible, evitaría los accesos a la BD
por cada impresión. Idealmente, sólo haría accesos cada intervalos de
tiempo fijo.
Saludos
2008/10/14 Juan P. [email protected]:
Nunca lo use, pero es cuestion de investigarlo.
http://github.com/coolblade/rails-ad-server/tree/master
Como dice en su README “I apologize in advance as this is still a work
in progress”.
No se si lo meteria en producción.
2008/10/14 Adrián Mugnolo [email protected]:
Sà podrÃas hacer la aplicación de gestión pero a la hora de servir los
avisos te recomendarÃa algo de más bajo nivel que Ruby y Rails.
PodrÃa ser PHP o un módulo en C (si tienes alguien cerca que pueda
mantener el código). Si fuera posible, evitarÃa los accesos a la BD
por cada impresión. Idealmente, sólo harÃa accesos cada intervalos de
tiempo fijo.
Hace unos dias estuvimos comentado lo mismo en la lista, yo propuse
utlizar ficheros de texto para controlar los accesos a los anuncios.
Lo que pasa es que entonces es más complicado controlar en número de
impresiones … etc.
Puedes ver algunos resultado en plan rápido en el siguiente enlace:
http://lists.simplelogica.net/pipermail/ror-es/2008-October/018044.html
Yo creo que tambien se puede utilizar Ruby a muy bajo nivel, creo que
el bottleneck serà normalmente la base de datos. No?
2008/10/14 Francesc E. [email protected]
utlizar ficheros de texto para controlar los accesos a los anuncios.
Lo que pasa es que entonces es más complicado controlar en número de
impresiones … etc.
Usando drb en un before filter con un demonio, no es muy complicado, y
presenta bastante buen rendimiento. Más o menos como hace newrelic que
cachea en un demonio drb.
On Oct 14, 2008, at 5:44 PM, Guillermo wrote:
Usando drb en un before filter con un demonio, no es muy complicado,
y presenta bastante buen rendimiento. Más o menos como hace newrelic
que cachea en un demonio drb.
Te refieres a delegar en un servidor drb corriendo en paralelo todo el
conteo de las impresiones y clicks, ¿no?
Me gusta la idea, añadimos un poco de complicación en la
implementación y tenemos que monitorizar un demonio mas, pero
obtenemos los datos en tiempo real y nos quitamos todos los problemas
del procesado.
Puede que tire por este camino a la hora de refactorizar mi sistema.
On Tue, Oct 14, 2008 at 6:28 PM, Felipe T. Armero <
[email protected]> wrote:
Me gusta la idea, añadimos un poco de complicación en la
implementación y tenemos que monitorizar un demonio mas, pero
obtenemos los datos en tiempo real y nos quitamos todos los problemas
del procesado.
Puede que tire por este camino a la hora de refactorizar mi sistema.
Me gusta pensar implementaciones pero luego no implemento nada. Lo que
tenÃa
pensado, ya que me das bola, es un buffer en drb con un tamaño máximo y
que
tras X criterios, hiciese dump a la base de datos con contadores.
Limitar a
un mega insert al dÃa/hora/minuto en la base de datos de estadÃsticas.
El servidor y cliente drb son apenas 6 lineas (3 clientes/3 servidor), y
lo
he usado para que postfix hable con la applicación rails, sin tener que
recargar la aplicación en cada e-mail. El resultado aparentemente fue
estupendo.
Podrías usar memcached para comunicar la aplicación de gestión con lo
que sea que sirva tus clientes, campañas, avisos, etc. Las
impresiones se podrían informar de vuelta al sistema cada tanto tiempo
ya sea que lo hagas a través de la BD, memoria, sockets, archivos u
otra forma.
En cuanto al cuello de botella, depende… PHP, Lua o C seguro serán
más rápidos que Ruby en cualquier combinación de servidor web + base
de datos + comunicación, etc. Esto no quita que puedas conseguir muy
buenos resultados con Ruby.
2008/10/15 Juan m. Blasco [email protected]:
Gracias Juan P… Es mas o menos lo que buscaba, pero lo cierto que su
carencia de entorno admin es un punto debil.
Aix, si utilizarais Typus … 
Me gustaria añadir algo a la discusion abierta acerca de las
prestaciones de los ad servers.
A) partamos de la base de que domino C desde hace 15 años, asi como Unix
y otros S.O. serios también.
B) es logico que sea mas rápido escribir un fichero de log con las
estadisticas que una BD. El lenguaje C, Ruby o …x … da igual, pues
el tiempo se consume fuera del entorno de estos lenguajes.
C) El autentico problema es el multiproceso (multihilo realmente). Si
cuando servimos el ad (un jpg o similar) debemos apuntar las
estadisticas en una BD dentro del mismo proceso, ANTES de devolerlo al
cliente (por culpa de la forma de trabajo de los web servers o de
nuestros mongrels) este tiempo computa dentro del total de servicio de
los ads.
Ahora bien, si el proceso principal DELEGA en otro proceso (otra thread
mejor) la parte de apunte en BD, el servicio de los ads no sufre
retardos añadidos y entonces es indistinto usar o no BD y solo influye
la velocidad del cgi en servir el fichero (mongrel, lighttpd u otro
metodo).
Puñeta, los mongrel no tienen multihilo, ni multiproceso, ni
multileches. Dicen que tras Ruby 2.0 y el consiguiente Rails (seria 3.0)
puede que los haya.
Yo los he utilizado en J2EE con los servlets (el multihilo) en algunos
proyectos y eso si que mola, y funciona.
Nota: los de PHP creo que tendran el mismo problema, luego el OpenX
tendra el inconveniente de la velocidad pues usa la BD para apuntar.
Nota2: se me ocurre que podemos delegar la tarea en un proceso conectado
por una PIPE, de forma que el cgi (mongrel) escriba en un fichero de log
(PIPE) y al otro lado este nuestro maravilloso proceso2 (escrito en ruby
outside rails y lanzado por un cron. Yo he hecho esto ya en algun
proyecto) que sea el que haga el apunte en la BD. Su tiempo de ejecucion
no formaria parte del tiempo de servicio del cgi (mongrel) y ese
problema solucionado.
2008/10/15 Juan m. Blasco [email protected]:
C) El autentico problema es el multiproceso (multihilo realmente). Si
cuando servimos el ad (un jpg o similar) debemos apuntar las
estadisticas en una BD dentro del mismo proceso, ANTES de devolerlo al
cliente (por culpa de la forma de trabajo de los web servers o de
nuestros mongrels) este tiempo computa dentro del total de servicio de
los ads.
Partiendo de mi desconocimiento …
Cuando sirves un anuncio puedes hacer un “detach” del proceso
utilizando algo como el run_later de Merb, pero en Rails, de manera
que lo sirves rápido, anotas estadÃsticas y realizas los procesos que
tengas que hacer.
Tambien pueder meter ese proceso en una cola para irlos procesando más
tarde.
Como no se magnificar los cientos de miles de anuncios que se pueden
llegar a servir, no se si mi “idea de ad server” funcionaria, pero al
menos la tendrias funcionando, y a partir de allà la podrias escalar.
Comentar que nosotros imprimimos hace unos meses casi 10 millones de
anuncios y no hubo mucho problema.
Tambien comentar que toda la parte de servidor de anuncios se puede
gestionar via Google Analytics, por lo que gran parte de la carga se
la llevan ellos, eso si, no tendras las estadisticas a tiempo real.
Juan P. wrote:
Nunca lo use, pero es cuestion de investigarlo.
GitHub - f3z0/rails-ad-server: Rails Ad Server (RAdS) is a simple ad server created to manage rotating ads and handling campaign budgets.
Gracias Juan P… Es mas o menos lo que buscaba, pero lo cierto que su
carencia de entorno admin es un punto debil.
Simplemente OpenX, aunque corra en PHP, es lo que necesito, pero tener
que aprender PHP a mis años es un dolor terrible. (intentare usarlo sin
aprender PHP).
2008/10/15 Francesc E. [email protected]
2008/10/15 Juan m. Blasco [email protected]:
Tambien comentar que toda la parte de servidor de anuncios se puede
gestionar via Google Analytics, por lo que gran parte de la carga se
la llevan ellos, eso si, no tendras las estadisticas a tiempo real.
Estoy encontrando muy interesante el hilo… al punto de incluso
interesarme
por hacer un proyecto para saber como funcionan los servidores de ads
XD.
Francesc… ¿podrÃas detallar un poco más este último punto de
la integración via google Analytics… te refieres a que se puede
integrar un
servidor externo (no-google) de ads dentro del analytics?.
Gracias a la gente de este hilo por mantener la conversación.
Francesc, run_later es una buena solucion para este caso. Tiene la
simplicidad de un plug-in de Rails y suena muy bien.
Pero plantearia quizas algun problema de concurrencia en ciertos
proyectos/usos. Esto se debe a que cada mongrel tiene una thread para
run_later. De todos modos la concurrencia accedindo a la BD no plantea
logicamente ningun problema, luego para servir los ads y delegar el
apunte de estadisticas a un momento despues de concluir el proceso del
cgi es simplemente perfecto.
2008/10/15 Aitor Garcia R. [email protected]:
Estoy encontrando muy interesante el hilo… al punto de incluso interesarme
por hacer un proyecto para saber como funcionan los servidores de ads XD.
Francesc… ¿podrÃas detallar un poco más este último punto de
la integración via google Analytics… te refieres a que se puede integrar un
servidor externo (no-google) de ads dentro del analytics?.
Gracias a la gente de este hilo por mantener la conversación.
Todo depende de que sea lo que se considera como un AdServer. Yo
siempre he oido problemas con los AdServer por temas de rendimiento, y
lo que siempre me han recormendado es utilizar aplicaciones externas.
De la manera que lo hicimos nosotros (o sea yo) es …
-
El cliente pide salir en la o una web durante un mes, o 10.000
impresiones … (aqui cada uno puede hacer las virguerias que quiera). -
Se hacer el random, y se le manda el anuncio, el en su web tiene un
js que se encarga de hacer la llamada del anuncio. Esto queda
contabilizado en nuestros servidores, a partir de ese momento el
click, lo gestiona el cliente, y eso queda integrado en su Google
Analytics.
Quizas es una versión un poco simplista de como deberia funcionar un
ad-server, pero el modelo de funcionar, funciona y bastante bien.
2008/10/15 Francesc E. [email protected]
2008/10/15 Juan m. Blasco [email protected]:
Francesc, run_later es una buena solucion para este caso. Tiene la
simplicidad de un plug-in de Rails y suena muy bien.Pero plantearia quizas algun problema de concurrencia en ciertos
proyectos/usos. Esto se debe a que cada mongrel tiene una thread para
run_later.
Coño, tener un hash en memoria con los clicks y cada 5 minutos o cada
1000
visualizaciones o cada “lo que te de la gana” volcarlo en la base de
datos
no supone un gran esfuerzo, y es capaz de escalar todo lo que quieras.
Solución más seria y sin mucha lio, es hacer el demonio drb(además te
quitas
temas de concurencia de los que te tienes que preocupar en caso de usar
un
hash en memoria), un sistema de colas o cualquier cosa que sirva de
buffer.
También tienes la opción de insert delayed, aunque para mi gusto es una
opción más delicada ya que es más coñazo depurar en caso de fallo.
2008/10/15 Juan m. Blasco [email protected]:
Francesc, run_later es una buena solucion para este caso. Tiene la
simplicidad de un plug-in de Rails y suena muy bien.Pero plantearia quizas algun problema de concurrencia en ciertos
proyectos/usos. Esto se debe a que cada mongrel tiene una thread para
run_later. De todos modos la concurrencia accedindo a la BD no plantea
logicamente ningun problema, luego para servir los ads y delegar el
apunte de estadisticas a un momento despues de concluir el proceso del
cgi es simplemente perfecto.
Si si … entiendo lo que dices, antes he comentado que no sabia
cuantificar el volumen de anuncios que queriais servir.
Si me dices que quieres servir 50.000 anuncios al dia, de diria que
ningun problema, pero si me dices que quieres servir un billon (de los
nuestros o americanos) entonces seguro que tendriamos que buscar otras
vias.
2008/10/15 Guillermo [email protected]:
Coño, tener un hash en memoria con los clicks y cada 5 minutos o cada 1000
visualizaciones o cada “lo que te de la gana” volcarlo en la base de datos
no supone un gran esfuerzo, y es capaz de escalar todo lo que quieras.
Solución más seria y sin mucha lio, es hacer el demonio drb(además te quitas
temas de concurencia de los que te tienes que preocupar en caso de usar un
hash en memoria), un sistema de colas o cualquier cosa que sirva de buffer.
También tienes la opción de insert delayed, aunque para mi gusto es una
opción más delicada ya que es más coñazo depurar en caso de fallo.
Nosotros eso lo haciamos con starling, de ahà salió
simplified_starling, que al mismo tiempo lo usabamos para otras cosas.
Lo que no se me ocurrió era procesar cada x tiempo, sino que lo
haciamos tal y como iba entrando.
Que no me salte nadie a la yugular … DRb es lo bastante rà pido para
procesar mensajes? Creo que hice las pruebas pertienentes en ese
momento, por lo que me quedé con starling, que al mismo tiempo no es
tan rà pido como Beanstalkd, pero lo elegimos por la persistencia de la
cola.