Hola amigos:
Leo asiduamente esta lista y en alguna oportunidad he contestado aunque
no
soy un conocedor de Rails.
Tengo un inconveniente desde hace unos dÃas que tiene que ver con el
manejo
de Threads.
Mi controlador hace lo siguiente …
class TontoController < ApplicationController
def mas_tonta_accion_aun
10.times{ |i|
if se_cumple_alguna_condicion
redirect_to :algun_lado
return
end
sleep 1
}
redirect_to :algun_otro_lado
end
end
La idea es, antes de redirigir a una página al navegador, hacer esperar
al
usuario unos segundos para ver si se produce algún evento especÃfico que
cambie el destino o la respuesta.
El problema surge que mientras el rails está ciclando en el times, otro
usuario no puede conectarse al servidor.
Esto se produce, a mi entender, porque tanto Mongrel como Webrick llaman
al
Dispatcher con un semáforo que impide la concurrencia.
Se me ocurren tres soluciones …
Abrir varios procesos mongrel o webrick en puertos distintos, y
tratar de
configurar un apache con balance de carga para que utilice los procesos
inactivos.
Reescribir el Mongrel o el Webrick para que no utilice el semáforo
(al
menos para esto).
Dejarme de jorobar con ciclos, threads y todo eso y llamar
repetidamente
con un Ajax al servidor hasta que se cumpla la condición (es lo que
estoy
haciendo ahora)
El inconveniente en el punto dos, es que el ActiveRecord utiliza una
única
conexión a la base de datos, por lo cual, tendrÃa que utilizar una
conexión
por cada llamado al Dispatcher, cosa que (lamentablemente) no he podido
hacer. En postgres, allow_concurrency me da falso.
El inconveniente del punto tres es la cantidad de veces que tiene que
llamar
el navegador al servidor.
Silvio, Rails no es thread-safe, asi que la alternativa #2 no es
posible (al menos no hoy en dia, y el mensaje que han dado en rails-
core es que no vale la pena el esfuerzo).
Todas las soluciones de servidores para Rails usan multiples
“servidores de aplicacion” (es decir, instancias de rails corriendo
tras un dispatcher fcgi o mongrel) en frente de uno o mas “servidores
web” que se encargan de balancear la carga (lighttpd para fcgi, nginx
o apache 2.2 para mongrel http)
Puedes argumentar que esto no es tan eficiente como podria ser si
activerecord fuera thread-safe y pudieras manejar multiples threads en
un solo servidor. Pero como de costumbre en rails la practicidad le
gana a la eficiencia. Y tarde o temprano (idealmente, si tu proyecto
se hace popular) vas a tener que manejar mas de un servidor, asi que
no puedes evitar tener que lidiar con balanceo de carga.
Hola , desde el punto de popularidad , en una aplicación Rails, ¿cuando
se
hace necesario tener mas de un servidor? como medimos eso? cantidad de
requests, uploads ??
hay algun articulo, slide, post, hilo al respecto??
Hola , desde el punto de popularidad , en una aplicación Rails,
¿cuando sehace necesario tener mas de un servidor?
La pregunta del millon :). En principio, mucho depende de tu
aplicacion.
La Facil : cuando los usuarios se quejan; cuando tu sitio esta caido;
cuando lo notas lento; etc. Aunque si, puede no ser muy profesional
:).
En [1] hablan un poco sobre escalabilidad, request/segundos y otros
temas que te pueden interesar.
Tambien en algunos de los videos de los Casos de exito algunos tiran
sus tips sobre como calculan (ahora me viene a la mente que en alguno
se habla, por ejemplo, de 40 mongrels por core de CPU que tiene la PC
o cosas asi).
Puedes argumentar que esto no es tan eficiente como podria ser si
activerecord fuera thread-safe y pudieras manejar multiples threads en un
solo servidor. Pero como de costumbre en rails la practicidad le gana a la
eficiencia. Y tarde o temprano (idealmente, si tu proyecto se hace popular)
vas a tener que manejar mas de un servidor, asi que no puedes evitar tener
que lidiar con balanceo de carga.
MuchÃsimas gracias por tu respuesta!
Silvio
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.