Escalabilidad de Ruby on Rails versus PHP

Question

¿Alguien puede comentar cuál es más escalable entre RoR y PHP? He oído que RoR es menos escalable que PHP, ya que RoR tiene un poco más de sobrecarga con su framework MVC, mientras que PHP es más bajo y más ligero. Esto es un poco vago, ¿alguien puede explicar mejor?

Answer 1

MVC es el acrónimo de Modelo-Vista-Controlador, un patrón de diseño común y conocido que pretende establecer una distinción clara entre su lógica empresarial (por ejemplo, el Modelo) y la capa de presentación (Vista y Controlador). Esto se ha cubierto extensamente en la web y SO, así que simplemente haga una búsqueda.

RoR es un framework que gira en torno a MVC y ActiveRecord construido sobre el lenguaje de programación Ruby, como Zend Framework o Symfony es un framework construido sobre el lenguaje de programación PHP. Comparar la escalabilidad de un marco con un lenguaje es comparar manzanas y peras.

En cuanto a la escalabilidad de RoR: sí, RoR fue criticado por escalar mal en 2008 cuando Twitter tuvo algunos problemas de rendimiento con él. Esto fue refutado por varias personas poco después. Y aunque no estoy enraizado en la comunidad RoR, mi suposición es que RoR escala, si lo haces correctamente. Pero tenga en cuenta que la necesidad de escalabilidad es algo que la mayoría de nosotros desearíamos tener, pero realmente no es así.

Así que a menos que tengas que tomar una decisión comercial importante entre usar Ruby o PHP, no te preocupes por cómo se escalan. Y si tiene, considere contratar consultores antes de preguntar aquí. Y nunca pierdas tu tiempo en flamewars entre idiomas.

Answer 2

Editar: Gordon +2. +1 para respuesta y +1 para el comentario! :)

La escalabilidad de un marco está restringida al almacenamiento en caché, almacenes de sesiones, reducción en el número de solicitudes HTTP, incluso partes de la interfaz de usuario de la aplicación como creación de sprites, almacenamiento en caché de archivos js, etc. Puede usar RoR/ZendPHP/CakePHP, cualquiera que sea la misma cosa al final. La ventaja de usar RoR es que sigue el paradigma MVC puro. Es más fácil concentrarse en la lógica de su negocio en lugar de perder tiempo en la configuración. Ahí es donde RoR tiene éxito sobre cualquier otro marco.

La escalabilidad también se ocupa del ORM utilizado por un marco. Cuanto más rápidas sean las operaciones de lectura/escritura, mejor será el rendimiento. Pero si no desea utilizar un marco completo, siempre puede optar por micro-frameworks como sinatra, camping, etc., que reducen un poco la sobrecarga. Rails también ha presentado Rails Metal, que está construido sobre bastidor, que puede utilizarse, por ejemplo, para tareas recursivas y, de ese modo, aumentar su rendimiento.

En realidad, la escalabilidad de una aplicación se trata principalmente de su hardware más que el software involucrado. También se trata de cómo organizar sus datos en la base de datos. Por ejemplo, Google usa BigTable en lugar de un RDBMS (como MySQL, PostGreSQL, SQLlite3, etc.) para una lectura y escritura más rápidas. En última instancia, depende de tu aplicación.

sugeriría que pasa el tiempo viendo esta presentación por Adam Wiggins, fundador de Heroku:

Horizontal Scalability via Transient, Shardable, and Share-nothing Resources

Answer 3

Ambos son bastante lento.

Ruby es realmente muy lento, con una gran huella de memoria, pero un lenguaje agradable y elegante.

PHP es un poco más rápido que Java y dot Net pero aún bastante lento.

C, pascal o ml son algunos órdenes de magnitud más rápidos, pero a la mayoría de las personas les resulta mucho más lento escribir aplicaciones web en ellos.

Mi sugerencia es poner un proxy inverso de equilibrio de carga Nginx en el frente y luego elegir su marco de trabajo, esto le permite agregar en un número bastante bien ilimitado de instancias. Si le importan los costos de hardware y electricidad, opte por una pila más eficiente. La parte clave es la memoria caché inteligente.

Tenemos un millón de usuarios en un par de máquinas virtuales Nginx funcionando a carga mínima debido al almacenamiento en caché sensible. El contenido dinámico es una mezcla de cosas y al menos 1000 veces más intensivo en recursos que el caché. La clave para el almacenamiento en caché es que no necesita volver a nada para verificar que el caché esté actualizado, esa fue nuestra mejor decisión de diseño.

Utilizamos una mezcla de C, C++, PHP, C#, Java, Python y Ruby, dependiendo de lo que queremos lograr.

Hay un buen artículo de blog sobre el Ruby escalabilidad mediante la configuración de las máquinas de forma automática utilizando la marioneta en http://highscalability.com/blog/2011/6/13/automation-on-aws-with-ruby-and-puppet.html

Tenemos un conjunto similar usando la marioneta para todas nuestras máquinas virtuales. El único problema es que Puppet normalmente usa la mayoría de los recursos para cualquiera de nuestras máquinas que no son Ruby. Entonces realmente nos gustaría reescribir Puppet en algo menos intensivo que Ruby.