ruby on rails - precio - ¿Hay puntos de referencia que comparen el uso de memoria respectivo de django, rails y frameworks PHP?
ruby on rails vs laravel (3)
Acabo de tropezar con este punto de referencia que se ve bastante bien. Simplemente proporciona datos sobre el uso (y el rendimiento) de la memoria de Rails, pero solo responde parcialmente la pregunta porque no compara los rieles con otros marcos.
Tengo que ejecutar un servidor web con muchos servicios en un servidor incrustado con RAM limitada (1 GB, sin intercambio). Habrá un máximo de 100 usuarios. Tendré servicios como un foro, pequeños juegos (javascript o flash), etc.
Mi equipo conoce muy bien a Ruby on Rails, pero estoy un poco preocupado por el uso de memoria de Rails. Realmente no quiero comenzar un troll aquí, pero me pregunto si hay puntos de referencia serios (es decir, documentados) que comparen Rails, Django, CakePHP o cualquier otro marco PHP.
¿Podría señalar puntos de referencia o darme su opinión sobre el uso de memoria de Rails? Por favor, por favor, no troll.
Mi propia experiencia es que el uso de la memoria de Rails puede ser alto, especialmente en máquinas de 64 bits (mínimo es de alrededor de 95-100 MB con thin como front-end web). PHP tiende a ser utilizado con diferentes patrones, por lo que es un poco difícil de comparar directamente.
En términos de uso de memoria, generalmente será Python> Ruby> PHP, que por supuesto conduce a Django> Rails> CakePHP. No solo la memoria, sino que también tiende a mantenerse por rendimiento bruto. EDITAR: También vale la pena señalar que, por supuesto, no hay absolutos aquí. Hay muchos escenarios de uso en los que Ruby vencerá a Python, sin dudas. Creo que todos podemos estar de acuerdo en que Ruby y Python siempre vencerán a PHP, sin embargo :)
Aquí hay un benchmarking directo de 3 vías (con Symfony en el lado de PHP de las cosas) que confirma lo anterior: http://wiki.rubyonrails.com/rails/pages/Framework+Performance . Aunque, por supuesto, es fácil encontrar estadísticas para apoyar tu propio punto de vista :)
Dicho esto, todavía es muy fácil hacer una aplicación Django cutre, lenta e ineficiente y una aplicación Rails delgada, rápida y eficiente, o viceversa. La habilidad, el conocimiento y la experiencia con el sistema que está utilizando harán mucho más por su memoria y el rendimiento que solo el marco. Las optimizaciones de las bases de datos, las selecciones de servidores y las arquitecturas (Apache frente a las configuraciones de proxy que utilizan nginx / lighttpd, etc.) y las decisiones de diseño fundamentales probablemente van a sobrepasar las características inherentes del marco rápidamente.
Así que supongo que lo que estoy diciendo es que si su equipo conoce a Rails, y su experiencia radica en Rails, me quedaría con Rails.