Forum: Rails-ES Ad server

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.
Bc50a89bc75c8f7dda50746164da92a4?d=identicon&s=25 Juan m. Blasco (jmblasco64)
on 2008-10-14 11:20
¿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,
Adce10d7f1dbabcdab8f525a59cec32f?d=identicon&s=25 Andrés Gutiérrez (andresgutgon)
on 2008-10-14 12:50
(Received via mailing list)
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 <
ruby-forum-incoming@andreas-s.net> escribió:
459459fe8b58c9dec54e8d1f2d84911c?d=identicon&s=25 Juan Pablo (Guest)
on 2008-10-14 14:05
(Received via mailing list)
Nunca lo use, pero es cuestion de investigarlo.
http://github.com/coolblade/rails-ad-server/tree/master
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-14 14:07
(Received via mailing list)
2008/10/14 Juan Pablo <juanpare@gmail.com>:

> 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.
0f727db8f255bf1e8665f5cd8ebe9f8c?d=identicon&s=25 Adrián Mugnolo (Guest)
on 2008-10-14 14:12
(Received via mailing list)
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
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-14 14:24
(Received via mailing list)
2008/10/14 Adrián Mugnolo <adrian@giro54.com>:

> 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/200...

Yo creo que tambien se puede utilizar Ruby a muy bajo nivel, creo que
el bottleneck serà normalmente la base de datos. No?
0f727db8f255bf1e8665f5cd8ebe9f8c?d=identicon&s=25 Adrián Mugnolo (Guest)
on 2008-10-14 16:27
(Received via mailing list)
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.
39086eb3d9a1437276d07c08ea0c3821?d=identicon&s=25 Guillermo (Guest)
on 2008-10-14 17:45
(Received via mailing list)
2008/10/14 Francesc Esplugas <francesc.esplugas@gmail.com>

> 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.
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-14 18:28
(Received via mailing list)
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.
39086eb3d9a1437276d07c08ea0c3821?d=identicon&s=25 Guillermo (Guest)
on 2008-10-14 21:58
(Received via mailing list)
On Tue, Oct 14, 2008 at 6:28 PM, Felipe Talavera Armero <
felipe@iniestahoy.com> 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.
Bc50a89bc75c8f7dda50746164da92a4?d=identicon&s=25 Juan m. Blasco (jmblasco64)
on 2008-10-15 11:11
Juan Pablo wrote:
> Nunca lo use, pero es cuestion de investigarlo.
> http://github.com/coolblade/rails-ad-server/tree/master

Gracias Juan Pablo. 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).
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-15 11:13
(Received via mailing list)
2008/10/15 Juan m. Blasco <ruby-forum-incoming@andreas-s.net>:

> Gracias Juan Pablo. Es mas o menos lo que buscaba, pero lo cierto que su
> carencia de entorno admin es un punto debil.

Aix, si utilizarais Typus ... ;)
Bc50a89bc75c8f7dda50746164da92a4?d=identicon&s=25 Juan m. Blasco (jmblasco64)
on 2008-10-15 11:26
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.
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-15 11:44
(Received via mailing list)
2008/10/15 Juan m. Blasco <ruby-forum-incoming@andreas-s.net>:

> 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.
5cf0355f5b2cc4bdc525f87330109cab?d=identicon&s=25 Aitor Garcia Rey (Guest)
on 2008-10-15 12:12
(Received via mailing list)
2008/10/15 Francesc Esplugas <francesc.esplugas@gmail.com>

> 2008/10/15 Juan m. Blasco <ruby-forum-incoming@andreas-s.net>:
>
>
> 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.
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-15 12:25
(Received via mailing list)
2008/10/15 Aitor Garcia Rey <aitor@linkingpaths.com>:

> 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 ...

1. 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).

2. 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.
Bc50a89bc75c8f7dda50746164da92a4?d=identicon&s=25 Juan m. Blasco (jmblasco64)
on 2008-10-15 12:30
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.
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-15 12:37
(Received via mailing list)
2008/10/15 Juan m. Blasco <ruby-forum-incoming@andreas-s.net>:

> 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. ;)
39086eb3d9a1437276d07c08ea0c3821?d=identicon&s=25 Guillermo (Guest)
on 2008-10-15 12:54
(Received via mailing list)
2008/10/15 Francesc Esplugas <francesc.esplugas@gmail.com>

> 2008/10/15 Juan m. Blasco <ruby-forum-incoming@andreas-s.net>:
>
> > 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.
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-15 13:04
(Received via mailing list)
2008/10/15 Guillermo <guillermo@cientifico.net>:

> 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.
39086eb3d9a1437276d07c08ea0c3821?d=identicon&s=25 Guillermo (Guest)
on 2008-10-15 14:31
(Received via mailing list)
2008/10/15 Francesc Esplugas <francesc.esplugas@gmail.com>

> 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.


He estado haciendo pruebas MUY POCO CIENTÍFICAS con drb y estos son los
resultados y código. El entorno un powerbook g4 con el ruby de serie de
osx
10.5.

Los resultados son los esperados, y se podría concluir que drb es lento
a la
espera de comparar resultados con starling (a ver si esta tarde saco
tiempo
o si puedes implementar un ejemplo parecido), permitiéndome un máximo de
600
peticiones por segundo.

Salvando comparativa con starling, en mi máquina, una simple operación
de
suma remota en drb está limitada a unas 600 peticiones por segundo. Por
lo
que incluso usando drb, habría que bufferear para obtener un rendimiento
decente con mucha carga.



Kakafuti2:drbtest guillermo$ ruby server.rb & sleep 2 ; ruby client.rb ;
fg

[1] 3408

I, [2008-10-15T14:09:15.634353 #3410]  INFO -- : Connecting to server

I, [2008-10-15T14:09:15.638425 #3410]  INFO -- : Tring increase in
server

I, [2008-10-15T14:09:25.658296 #3410]  INFO -- : Total user time in 10
> seconds for #<Counter:0xa0b04>.increase with 6387 calls: 4.7

I, [2008-10-15T14:09:25.659619 #3410]  INFO -- : Trying increase in
local

I, [2008-10-15T14:09:35.668056 #3410]  INFO -- : Total user time in 10
> seconds for #<Counter:0x89850>.increase with 5163733 calls: 9.45

I, [2008-10-15T14:09:35.669428 #3410]  INFO -- : Trying system in server

I, [2008-10-15T14:09:45.695523 #3410]  INFO -- : Total user time in 10
> seconds for #<Counter:0xa0b04>.sys with 772 calls: 0.989999999999999

I, [2008-10-15T14:09:45.696871 #3410]  INFO -- : Trying system in local

I, [2008-10-15T14:09:55.701216 #3410]  INFO -- : Total user time in 10
> seconds for #<Counter:0x89850>.sys with 956 calls: 0.24

ruby server.rb

^Cserver.rb:5:in `join': Interrupt

from server.rb:5


> Kakafuti2:drbtest guillermo$


counter.rb

> class Counter

  def initialize; @count,@utime = 0,Process.times.utime; end

  public :initialize

  def utime; Process.times.utime - @utime ; end

  def increase; @count = @count+1; end

  attr_reader :count

  def sys; @count = @count+1 ; %x(ls); nil; end

end


server.rb

> require 'drb/drb'

require 'counter'


> DRb.start_service("druby://localhost:8787",Counter.new)

DRb.thread.join


client.rb

> %w(drb/drb timeout logger counter).each {|e| require e}


> @logger = Logger.new(STDOUT)

def log(msg); @logger.info msg ; end


> def timeout(obj,meth)

  obj.initialize

  Timeout::timeout 10 do

    obj.send meth while true

  end

rescue TimeoutError

  log "Total user time in 10 seconds for #{obj.to_s}.#{meth.to_s} with
> #{obj.count.to_s} calls: #{obj.utime}"

end


>
> log "Connecting to server"

server = DRbObject.new_with_uri("druby://localhost:8787")

local = Counter.new


> log "Tring increase in server"

timeout server, :increase

log "Trying increase in local"

timeout local, :increase

log "Trying system in server"

timeout server, :sys

log "Trying system in local"

timeout local, :sys
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-15 15:18
(Received via mailing list)
2008/10/15 Guillermo <guillermo@cientifico.net>:

> He estado haciendo pruebas MUY POCO CIENTÍFICAS con drb y estos son los
> resultados y código. El entorno un powerbook g4 con el ruby de serie de osx
> 10.5.

> Los resultados son los esperados, y se podría concluir que drb es lento a la
> espera de comparar resultados con starling (a ver si esta tarde saco tiempo
> o si puedes implementar un ejemplo parecido), permitiéndome un máximo de 600
> peticiones por segundo.

Benchmark que hice de Starling y Beanstalkd hace unos meses. El
benchmark mete 1000 items en una cola y despues los saca. [1]

Beanstalkd es mas rapido al hacer push en la cola por que no es
persistente.

             user     system      total        real
b:push   0.060000   0.030000   0.090000 (  0.153311)
b:pop    0.100000   0.040000   0.140000 (  0.290474)
s:push   0.040000   0.030000   0.070000 (  0.235342)
s:pop    0.060000   0.030000   0.090000 (  0.274897)

[1] http://github.com/fesplugas/snippets/tree/master/r...

Para no alejarnos del hilo comentar que sea la solución que sea, yo
creo que Rails puede ir escalando a medida que lo necesitemos.
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-28 19:08
(Received via mailing list)
On Oct 15, 2008, at 12:54 PM, Guillermo wrote:

> 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.


Done :-D

Tras unas semanas sacando por ahi ratillos, tengo una primera
implementación de todo esto en forma de plugin. Si os apetece pegarle
un vistazo y me contais que tal lo veis, yo ya lo tengo rulando en mis
apps :-)

Os presento stats_for_all =>
http://github.com/flype/stats_for_all/tree/master

Saludos
Felipe
F625b891618be8ec32547a07b3192bb0?d=identicon&s=25 Francesc Esplugas (fesplugas)
on 2008-10-29 00:02
(Received via mailing list)
Coñe si se puede utilizar con simplified_starling, me gusta ver que
hay gente que lo está usando.

Yo empeze a extraer de un proyecto un AdServer, pero veo que lo tuyo
está bastante avanzado. Has pensado en la manera de poder insertar
banners en otras webs?

Lo tienes funcionando em produccion en algun sitio?

On 28/10/2008, at 19:07, Felipe Talavera Armero
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-29 00:29
(Received via mailing list)
On Oct 29, 2008, at 12:02 AM, Francesc Esplugas wrote:

>
> Coñe si se puede utilizar con simplified_starling, me gusta ver que
> hay gente que lo está usando.
>
Pues cuando decidí usar starling estuve mirando varias opciones, entre
ellas, reinventar la rueda y implementar directamente el soporte de
starling, cosa que pronto deseché al ver que había bastante por ahi
hecho...  la otra fue elegir entre simplified_starling y workling,
pero jugando con las dos al final decidí usar simplified_starling por
la manera de levantar los servicios con rake, la implementación que la
vi mas sencilla y porque en principio estoy interesado en usar
starling por la persistencia y no ningún otro sistema de colas.


> Yo empeze a extraer de un proyecto un AdServer, pero veo que lo tuyo
> está bastante avanzado. Has pensado en la manera de poder insertar
> banners en otras webs?

Realmente mi idea ha ido un poco mas allá, no he querido hacer solo un
sistema que sirva para  estadísticas de ads, con el plugin puedes
sacar estadísticas de cualquier modelo y de cualquier tipo no solo
hits y clicks, puedes definir tus propios tipos.

La idea es utilizar una especie de sistema globalizado que pueda
guardar estadísticas de por ponerte un ejemplo las visitas de una
foto, al igual que hace flickr osea de cualquier recurso de tu
aplicación.
Claro está dentro de ese recurso están la publi, por lo que montar un
adserver, estaría ya chupado. :-p

> Lo tienes funcionando em produccion en algun sitio?

Aún no, estoy terminando la refactorización de un proyecto, cuando
esté lista le daremos cañita al plugin a ver como responde.
39086eb3d9a1437276d07c08ea0c3821?d=identicon&s=25 Guillermo (Guest)
on 2008-10-29 02:28
(Received via mailing list)
2008/10/28 Felipe Talavera Armero <felipe@iniestahoy.com>

> Os presento stats_for_all =>
> http://github.com/flype/stats_for_all/tree/master
>

Gracias por la mención.
He estado mirando el código y me gusta.

En StatsForAll::Client::InstanceMethods.drb_save haces una llamada a
DRb.start_service. Salvo que haya algo que me pierda, esta función te la
puedes comer directamente pese a que la documentación diga lo contrario.
Verás que el rendimiento en drb se dispara hasta ser transparate para un
humano.
A3217d68e477bf008a2eed6991ba86f8?d=identicon&s=25 Felipe Talavera Armero (Guest)
on 2008-10-29 09:55
(Received via mailing list)
On Oct 29, 2008, at 2:27 AM, Guillermo wrote:

> En StatsForAll::Client::InstanceMethods.drb_save haces una llamada
> a  DRb.start_service. Salvo que haya algo que me pierda, esta
> función te la puedes comer directamente pese a que la documentación
> diga lo contrario. Verás que el rendimiento en drb se dispara hasta
> ser transparate para un humano.

Ojú, que razón tienes, funciona exactamente igual y he ganado un 200%
de rendimiento :-D dejo unos benchmarks para el drb.

Para el servidor drb sin el start_service

                 user     system      total        real
direct      0.000000   0.000000   0.000000 (  0.001370)
drb-10      0.020000   0.000000   0.020000 (  0.034161)
drb-100     0.120000   0.010000   0.130000 (  0.226939)
drb-1000    1.490000   0.090000   1.580000 (  2.581357)
drb-10000  14.680000   0.830000  15.510000 ( 24.699897)

Y para el servidor con el:
                 user     system      total        real
direct      0.000000   0.000000   0.000000 (  0.001350)
drb-10      0.020000   0.000000   0.020000 (  0.249107)
drb-100     0.180000   0.050000   0.230000 (  0.462050)
drb-1000    2.130000   0.430000   2.560000 (  4.758769)
drb-10000  21.020000   4.310000  25.330000 ( 46.883869)

muchas gracias,  si vas viendo por ahi algo raro, coméntamelo.

Un saludo
Felipe
This topic is locked and can not be replied to.