Instalación de un servidor, consejo

Community ES
1

Hola lista.

Tenemos que montar un servidor Rails para una aplicación que
probablemente va a tener muchas visitas/usuarios. En otros servidores
hemos estado usando mongrel + apache y todo va bien pero ahora no
estoy seguro de que sea la opción más recomendable debido a que vamos
a tener un volumen de tráfico considerable. Estoy hecho un lío…
passenger, phusion passenger, nginx, etc etc.

¿Qué nos recomendáis instalar como servidor Rails?
¿Algún buen howto para dejar andando un buen servidor Rails?
Temas de caché, ¿con que lo hacéis?

Gracias!

2

Que es para ti un “volumen de tráfico considerable”?
Yo montaria apache/nginx + passenger, con nginx tendrás algo más de
rendimiento. Optimizas bien las consultas a la base de datos y usas
cache
donde puedas.

Si este stack no te da el rendimiento suficiente, hace pruebas con otro
stack, pero solo cuando realmente veas que esto no te sirve, no empieces
la
casa por el tejado.

PD: los de basecamp estan pasando a passenger (o ya lo utlizan, no se
seguro), y ellos si que tienen un volumen considerable.

2009/4/21 congrio [email protected]

3

Tenemos que montar un servidor Rails para una aplicación que
probablemente va a tener muchas visitas/usuarios. En otros servidores
hemos estado usando mongrel + apache y todo va bien
Ten en cuenta que hasta hace unos meses la opción para poner en
producción cualquier sitio en rails pasaba por mongrel. Sitios con mucho
tráfico usan esa solución sin problemas.

En cuanto a Apache, qué te voy a decir que no sepas. Está en todas
partes. Rails y no Rails.

Nginx tiene mejor rendimiento que Apache, y passenger simplifica los
deploys (y de paso en algunos casos te mejora el uso de memoria), pero
eso no significa que las soluciones anteriores no sean buenas. De hecho
si usabas passenger hasta hace dos días (literalmente) no
había opciónde montarlo en nginx, sino que había que ponerlo sobre Apache sí o
sí.
Vamos, que si quieres hacer la instalación standard ahora, lo más típico
sería un Apache+Passenger. Pero que lo otro te funcionará igualmente.

Y para la caché, lo más normal es tirar de memcache. Los sitios muy
gordos además de esa caché utilizan proxy caches del tipo squid, pero ya
cuando se empieza a necesitar esas cosas también suelen usarse CDNs y
otros recursos que en sitios a escala humana no hacen falta realmente.

saludos,

j

–
javier ramírez

…i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
…you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez

4

Gracias Emili y Javier.

Pues tiraremos por nginx + passenger y memcache

En cuanto a la pregunta “Qué es para ti un volumen de tráfico considerable?”
Pues, la verdad, buena pregunta… no sabría decirte.
Es una aplicación para un banco a nivel nacional, sus clientes (que el
primer día entrarán en masa y seguro que colapsan el sistema…) y para los
clientes, que entraran más progresivamente pero en mucha mayor cantidad.

Otra cosa que no tengo clara… tenemos un servidor dedicado para esta
aplicación con éstas características:
Intel Xeon Quad 4x 2.66+ GHz
8 GB DDR2
RAID 1
100 Mbps (hacia internet)
Ubuntu 8.10 (server 64bits)

Todo va a estar ahí, base de datos y demás servicios (puede que correo y
alguna cosa más). Se que sin saber que tráfico va a haber no se puede
asegurar nada, pero, como lo veis?

----- Mensaje original ----
De: javier ramirez [email protected]
Para: La lista sobre Ruby On Rails (rubyonrails.com) en castellano
[email protected]
Enviado: martes, 21 de abril, 2009 10:49:08
Asunto: Re: [Ror-es] Instalación de un servidor, consejo

Tenemos que montar un servidor Rails para una aplicación que
probablemente va a tener muchas visitas/usuarios. En otros servidores
hemos estado usando mongrel + apache y todo va bien
Ten en cuenta que hasta hace unos meses la opción para poner en
producción cualquier sitio en rails pasaba por mongrel. Sitios con mucho
tráfico usan esa solución sin problemas.

En cuanto a Apache, qué te voy a decir que no sepas. Está en todas
partes. Rails y no Rails.

Nginx tiene mejor rendimiento que Apache, y passenger simplifica los
deploys (y de paso en algunos casos te mejora el uso de memoria), pero
eso no significa que las soluciones anteriores no sean buenas. De hecho
si usabas passenger hasta hace dos días (literalmente) no
había opciónde montarlo en nginx, sino que había que ponerlo sobre Apache sí o
sí.
Vamos, que si quieres hacer la instalación standard ahora, lo más típico
sería un Apache+Passenger. Pero que lo otro te funcionará igualmente.

Y para la caché, lo más normal es tirar de memcache. Los sitios muy
gordos además de esa caché utilizan proxy caches del tipo squid, pero ya
cuando se empieza a necesitar esas cosas también suelen usarse CDNs y
otros recursos que en sitios a escala humana no hacen falta realmente.

saludos,

j

–
javier ramírez

…i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
…you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

5

Hola,

El otro día estuve leyendo un artículo interesante sobre saber
localizar tus cuellos de botella (entre otras cosas) a la hora de
trabajar con Rails. No propone una solución definitiva pero si expone
las diferentes herramientas que se pueden utilizar para encontrar en
qué parte de la aplicación hay que mejorar el rendimiento.

Un saludo y espero que te sirva :wink:

2009/4/21 congrio [email protected]:

¿Algún buen howto para dejar andando un buen servidor Rails?
Temas de caché, ¿con que lo hacéis?

Gracias!

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Carlos Matallín
[email protected]
http://c.matallin.com
+34 607377647

6

2009/4/21 congrio [email protected]

En cuanto a la pregunta “Qué es para ti un volumen de tráfico
considerable?” Pues, la verdad, buena pregunta… no sabría decirte.
Es una aplicación para un banco a nivel nacional, sus clientes (que el
primer día entrarán en masa y seguro que colapsan el sistema…) y para los
clientes, que entraran más progresivamente pero en mucha mayor cantidad.

Si sabes que vas a tener una demanda grande, y no sabes lo que puede
suponer, existen varios tiempos que debes de tener en cuenta, según mi
experiencia y escaso conocimiento:

  • El tiempo de desarrollo. Este tiempo es fijo, así que ante un colapso
    del
    sistema… no nos sirve.
  • El tiempo de desplegar una nueva máquina. Según el datacenter/compañía
    que
    estés, poner una máquina nueva pueden ser segundos trabajando en lo que
    llaman la Nueve(EC2), o semanas. Parece una tontería, pero para el
    cliente,
    no es lo mismo tener un downtime de unas horas a unos días. Además, si
    con
    otra máquina no es suficiente, tendrías que esperar el doble de tiempo.
    Con
    muchos servicios como EC2, puedes poner a monit para que levante otra
    instancia si la cola del mongrel es muy larga o si la carga de la
    máquina
    sobre 100 (que no el micro que tienes creo que no es tan descabellado).

Ante esta arquitectura, tendría una máquina al principio y según me
fuese
encontrando problemas seguiría más o menos así:

  • Lo primero sería sacar la base de datos a otra máquina.
  • Después según si la aplicación consume más recursos de bases de datos
    o de
    aplicación, pondría un esclavo a la base de datos, o más maquinas, con
    una
    máquina intermedia que balancesasen entre estas dos, o que ellas incluso
    se
    balancesasen entre sí. Añadiendo más IP al mismo dominio.

De forma paralela estudiar y solucionar cada cuello de botella.