No es la primera vez que atacan a Rails diciendo que no es escalable. En esta última ocasión, el desencadenante ha sido una entrada en TechCrunch acerca de que quizá Twitter abandonase Rails (desmentido ya por el propio Evan Williams en un tweet).
Rails NO es el problema.
Puedes hacer un desarrollo que soporte millones de usuarios al mes y puedes hacer desarrollos que no aguanten más de tres o cuatro peticiones por segundo. Ya sea con Ruby, con PHP, con Java o incluso si te pones con .NET.
Lo que decide si un sistema va a poder ser escalable o no es que en su momento hayas diseñado correctamente el modelo de datos. Que no hayas escatimado, pero tampoco hayas abusado, en los índices que vas a necesitar. Que no todo sea base de datos y te apoyes en ficheros de texto para ciertas cosas. Que tengas bien distribuidos los equipos que van a actuar como servidor de la aplicación, como servidor de ficheros, como cachés, como servidor de base de datos. Que sepas en qué proporción van a tener que ir creciendo dichos servidores. Que juegues con las cabeceras HTTP (benditas 304). Que conviertas a tu desarrollo en básicamente un generador de HTML estático que no toca base de datos a no ser estrictamente necesario.
El que lo hayas hecho en Rails, en Merb, en Django, en CakePHP o a pelo al final acaba siendo lo de menos… La clave de que teu proyecto escale es el trabajo antes de empezar a escribir la primera línea de código. Y aun así te encontrarás con problemas.
24 Comentarios
amen. Toda la razón. Pero de algo hay que trolear digo hablar.
Para mí eso cae de cajón (aunque para demasiados no). Lo que realmente importa es: ¿a igualdad de condiciones, Ruby (no Rails) escala del mismo modo que PHP o Java?. Es importante, ya que no siempre te puedes permitir el lujo de realizar aplicaciones donde todo sea cacheable. Si tenemos que generar HTML estático dame un buen servidor web y punto. Si tienes que procesar datos permanentemente, si tienes que tirar de DB permanentemente, ya hay que pensárselo seriamente. Y ya no me meto en Rails vs Zend Framework o CakePHP o lo que sea (que eso es otro mundo) si no en Ruby vs PHP. ¿Para servir 10 peticiones por segundo con consultas a la misma base de datos, necesito más potencia o memoria con Ruby, con PHP o con Java?. Eso es lo que debería importar a los desarrolladores y no discusiones como han sido EMacs vs Vim o similares….
David: Todo es cacheable. Si tienes que procesar datos permanentemente, y por ello tiras de DB permanentemente, algo falla en tu esquema.
Te sorprendería ver como el servidor de base de datos de 20minutos.es la mayoría del tiempo se está echando una siestecita. Y es un sitio que está recibiendo miles de comentarios, cientos de miles de usuarios al día.
Si, muchísimas cosas son cacheables, desde luego, pero no todas. Además, eso sigue sin ser la cuestión. Lo que importa es el tiempo que tarda Ruby en obtener esos datos, procesarlos y cachearlos frente a otras soluciones. De poco me vale Ruby si para exactamente el mismo trabajo necesito 4 servidores frente a 2 de PHP…
Si quieres comparar lenguajes, mira esto.
Sobre número de servidores que necesitarías, Ruby y PHP irían a la par. Java juega directamente en otra liga. Para la gran mayoría de estos lenguajes ya se cuenta con conectores nativos a los diferentes sistemas de bases de datos.
También hay que tener en cuenta más cosas. Las aplicaciones web hoy en dia no son solamente CMS para publicación de contenidos. Se hacen muchas aplicaciones web para intranets, donde la cantidad de datos insertados en las bases de datos es mayor que la cantidad de datos consultadas, y ahí no puedes cachear, y donde no puedes permitirte un servidor cojonudo en rack para ejecutar tus aplicaciones. Lo importante es que sirva para el mundo real…
Todo lo que puedes implementar en php, lo puedes hacer en ruby (y a la inversa). La cuestión es plantearlo bien. Luego ya el lenguaje puede marcar diferencias significantes sobretodo en el mantenimiento de la aplicación (la cual, si no se ha hecho bien, directamente no existirá ese mantenimiento, o si existe, a quien le toque tendrá ataques y tendencias suicidas).
En ese caso (y en mi opinión) ruby (y python) como lenguaje está años luz por delante del desastroso y caótico php. Y que conste que tengo bastante más experiencia en php que en ruby.
Ains… no hablamos de tener que cachear el 100% de los elementos el 100% del tiempo. Eso es imposible. La clave está en fragmentar bien y poder cachear la mayoría de esos fragmentos.
Blaxter, eso ya es más para gustos. Yo también creo que PHP es caótico, pero lo sigo prefiriendo a Ruby e incluso a Python con las buenas características que tiene (puede que cambie en un futuro, pero por ahora…). Lo que vale al final es si las cosas funcionan buen a gran escala, sea el lenguaje que sea. Si eres capaz de programar una aplicación cojonuda con RoR que aguanta lo que le echen, pues genial, y si te ha salido más barato que con PHP, pues ole!. Perl es minoritario pero hay software como Slashcode que sigue batiendo a CMS modernos. Todo es cuestión del planteamiento como hemos hablado, pero el rendimiento real también es una parte importante. Y que pocos proyectos realmente importantes se hayan llevado a cabo con Ruby supongo que también quiere decir algo…
Claro Mayoral, todo depende. Puede ser mas eficiente servir datos dinamicos que cachear trozos para luego ensamblarlos… Todo depende de lo que tengas y cómo lo tengas. También hay que pensar en casos como los que comenta Blaxter, en donde el mantenimiento es horrendo y resulta prácticamente imposible echarle mano, ahí tambien importa el rendimiento real…
hay que inventar siempre, pero de base lo dificilmente que no cambia no lo puedes estar construyendo dinamicamente, todo esto en back y por la noche, dependiendo de cada país(esta técnica no le sirve ni al twitter pero si a otros) esto es, para entenderlo mejor:
yo siempre digo lo mismo: lo estático no lo hagas dinámico y lo dinámico no lo hagas estático.
Para dar consultoría gratuita a twitter ;) yo haría: Estadística de usuarios, por sus horas, por sus medias, y asignar recursos en base a estos resultados.
Realmente lo tienen dificil no por el lenguaje/sistemas usados sino por la frecuencia de actualización que tienen,
También sería hacer una diferenciación entre el pool de mensajes 140 caracteres(parte muy dinámica de la aplicación) y el contorno que rodea a eso que es mucho más estático.
Todo esto como dice Luis se piensa antes de tirar la primera línea de código.
saludos y buen post Luis
Por favor, Mayoral: Respecto a tu comentario:
“Te sorprendería ver como el servidor de base de datos de 20minutos.es la mayoría del tiempo se está echando una siestecita. Y es un sitio que está recibiendo miles de comentarios, cientos de miles de usuarios al día.”
Segun veo en las ofertas de trabajo , se ve que lo tienen en PHP .No entiendo bien lo que quieiasres decir ¿como se consigue ese “desahogo” para servir info sin estra llamando a base de datos de contiinuo? ¿seria mejor usar un CMS/propio bajo Perl como Amazon para sitios de alto trafico? Gracias
Lajinn: Precisamente como comentaba, cacheando hasta la saciedad y sirviendo contenido estático siempre que es posible. PHP, Perl o lo que sea acaba siendo lo de menos en la mayoría de los casos.
Ajá . ya . O sea que daría igual desarrollar un sitio en Perl ò Python en lugar de PhP . No vamos a conseguir que nos aguante muchisimo mas trafico que PhP sólo por el lenguaje. PhP tambien puede hacerlo Es eso ¿verdad? Y con .NET ¿conseguiríamos servir millones de solicitudes a la semana? Gracias
Lajinn: Es eso. Y sobre lo de .NET… lo mismo. Todo depende de que montes bien la granja de servidores.
Muchas gracias, Mayoral Yo creía que la capacidad de gestionar sitios de muy alto tráfico dependía tambien del lenguaje de programacion del CMS. Sobre todo despues de los comentarios sobre Perl en la Wikipedia y muchas mas fuentes sobre Slashdot y de conocer Coranto,Bricolage ,Python (PyLucid CMS,TurboGears FW,Django FW), JAVA (compilado) , pero ya veo que con Drupal mismo se pueden hacer sitios de high traffic como The Onion,etc. Muchas gracias
Lajinn: El CMS te va a ayudar en la medida en la que esté preparado para temas de cacheo. Es como cuando te montas una bitácora y pones un Wordpress, que ya vas sabiendo que por narices acabarás instalando WP-Cache o WP-SuperCache porque sino esto no aguantará. Con Drupal te pasará igual, tendrás que instalar algunos de los módulos que hay para hacer cacheo en fichero y otro tipo de optimizaciones.
Mira alguno de los frameworks que precisamente me has nombrado… TurbogGears gracias a CherryPy, Django con su propio sistema. Mira en Perl Catalyst. O en Ruby Rails. Todos ellos tienen muy bien definido un sistema de caché, a nivel de ficheros, con memcached, de consultas…
A modo de curiosidad. ¿Sabías que la actual versión de motogp.com está basada en un Drupal? En concreto, se encargó de hacerla la gente de Alquimia, que cuenta ya a sus espaldas con más de un proyecto gordo basado en este CMS.
Me da en la nariz que el lenguaje va a tener algo que ver tambien. Me voy a http://www.trafficestimate.com/ y: motogp.com ha tenido 889,100 en los ultimos 30 dias theonion.com (el sitio de mas alto trafico hecho con Drupal) ha recibido 2,290,600 visitas http://www.plentyoffish.com (.NET) ha tenido 4,713,700 amazon.com (Perl) ha tenido 48,112,000 visitas Y de la Wikipedia, podemos leer: Todas las versiones de Perl hacen el tipificado automático de datos y la gestión de memoria
Me explicaré lo que voy persiguiendo, mejor. He dado con un nicho aún de casualidad, una tematica web que aun no existe y que aunque no llegue al alto trafico de amazon , se le puede acercar. Será un sitio internacional, porque en inglés hay mas gente que en español y antes que todos en chino
Pero tengo que tener muy bien definido tanto el lenguaje a desarrollar el sitio como el hardware Puedo llegar a alcanzar un minimo muy minimo de 2 millones de visita unica sólo en Europa
Ahora ya lo sabes. Como experto que eres ¿en que lenguaje me aconsejas que desarrolle el sitio? Java? Perl? Y respecto al hardware? Podría partir de compartidos de momento , muy de momento y montarme mi propia granja con servidores twin en casa y un buen UPS?
Perdoname si te molesto con tanta “tralla” , he entrado en este web por casualidad buscando info sobre “lenguajes programacion web alto trafico”. Ojala que no te sientas molesto. Gracias
Lajinn:Experto no soy. Partiendo de ahí mi consejo para tu lenguaje es que utilices en el que más cómodo te sientas.
Respecto a lo servidores, claro que puedes empezar con un compartido. Aunque tarde o temprano empezarás a tener servidores especializados en una tarea (uno o varios para contenido estático, uno o varios para la base de datos, etc). Esa es la parte crítica, hacerlo todo equilibrado.
Claro que influye el lenguaje. Desde luego. Marca la diferencia de necesitar 10 o 15 servidores. Tomemos la misma aplicación con los mismos datos (Digamos, Drupal…), con las mismas versiones de Apache, PHP y MySQL PERO comparando el rendimento a mismo número de peticiones sobre Mac, Windows y Linux, todo sobre exactamente la misma máquina. ¿Qué sistema operativo tarda menos tiempo en completar el mísmo número de peticiones?. Pues hagamos lo mismo pero en vez de variar el sistema operativo, variemos el lenguaje. ¿Quién gana?. Eso es lo que debe importar…
Dados los mismos parámetros, no da lo mismo cachear con PHP que con Ruby o Perl. ¿De qué me sirve usar Ruby si al procesar los datos antes de cachearlos me revienta el servidor?. ¿De qué me sirve usar Perl si para el mismo número de peticiones necesito 10 servidores en vez de 6 o 7?.
No todo es blanco ni negro (todo dinamico vs todo cacheado). Hay mil escenarios con mil soluciones diferentes, por eso es importante evaluar todos esos datos.
Eso es …. quien gana? El sitio lo voy a alojar en Copernico. De RoR se dice que es lento y cachea mas. Solo hay un CMS: Radiant , y para sitiosno muy grandes, así que a tirar de Framework La golosina de Drupal es que no hay que partir from scratch y tienes muchos recursos… pero es PhP Lo ideal es Python: practicamente hay un solo proyecto que se mueve algo: Pylucid. Sino: los framework Turbogears y Django En Perl tenemos para partir unos cuantos ya: Bricolage, WebApp, Coranto (ha desparecido de la red!), Webgui (sólo hay traducido al español un 31,5%, eso no es muy importante porque el inglés tiene muchísima mayor difusión, pero dado que soy español, que tambien este la gui en éste idioma),Krang,Mason,Movable Type (este dicen que consume demasiados recursos),Scoop, Metadot… Así que RoR descartado. De PhP sólo me gusta la infinidad de themes , addons y soporte hasta en español, si lo hubiera en Python de cabeza a él Me quedan Perl y Python y si no tengo mas remedio Drupal. Busco SEGURIDAD y capacidad de atender millones de accesos tal vez hasta a la semana ¿Te molestaría , David, si me ayudas con un empujoncito por cual me tiro? Gracias por tu amabilidad en adelantado
Pues, ¿Google App Engine?. Programas en Python con DJango y es Google quien se encarga de escalar, tú te olvidas del tema servidores…
Esta genial en cuanto a escabilidad. Pero esa beta esta limitada a 10.000 cuentas y ya se han agotado. Hay que esperar. De todas formas me inquieta estar aprisionado por Google y tener que usar un subdominio en lugar de mi propio dominio ya resgistrado en español e inglés. Las condiciones de uso de la aplicacion son preocupantes, entre otras, correrías el peligro de ser baneado y por motivos de seguridad algunos modddulos de python estan desactivados. Tambien la aplicacion que le da sentido a mi futura web esta desarrollada en PhP , de esa no puedo prescindir. El nucleo de mi web es eso y un foro no lleva mas…. y eso de alojar EN SUS SERVIDORES…ejem Lo que si esta quedando claro es que EL LENGUAJE se llama Python en primer lugar y que Drupal y Wordpress serán los siguientes en ser soportados por Google App Engine Tambien queda claro que salvando los problemas de escalabilidad RoR es tambien el lenguaje Saludos,
http://www.codinghorror.com/blog/archives/001131.html
Comparación pequeña pero significativa…