ruby on rails - ¿Debo usar haml, erb o erubis para un sitio potencialmente con mucho tráfico?
ruby-on-rails eruby (7)
Creo que es una cuestión de preferencias personales y mantenimiento. Para mí, Haml hace que las plantillas sean más fáciles de leer y comprender, y el rendimiento es muy aceptable. Al final, es improbable que el lenguaje de plantillas sea el lugar donde necesita optimizar: más consultas de bases de datos, caché de objetos o vistas, etc.
Sin embargo, en el caso de las plantillas de ERb, obtendrá un mejor rendimiento esencialmente gratis si usa erubis.
Recientemente he estado jugando con Haml y me gusta mucho la forma en que el código resultante me parece ... el desarrollador. Tampoco me preocupa demasiado que un diseñador pueda consumirlo o cambiarlo ... somos un equipo pequeño.
Dicho esto, comenzamos a trabajar en un proyecto que creemos generará bastante tráfico (¿quién no?). Me preocupa que haya cosas que simplemente no sé sobre haml. ¿Hay algo que Erb pueda hacer que Haml no pueda? ¿Haml tiene un efecto negativo a medida que crece un proyecto? ¿Hay otras cosas que deberían considerarse?
Y finalmente ... ¿cómo se compara Haml con el speedwise al erubis? Veo que supuestamente supera a erb y eruby ahora ...
¡Gracias!
Personalmente, nos recomendaría erubis en plantillas precompiladas.
Especialmente si no hay necesidad de plantillas dinámicas. Entonces, tu mayor ralentización estará limitada por la velocidad a la que el rubí puede analizar el rubí.
Probablemente configuré un pequeño trabajo cron que solo monitorea las plantillas de origen modificadas y las autocompila; cambio que se puede desactivar cuando no esté en uso.
Compila una vez, usa muchas.
Ah, y si realmente te preocupa la velocidad, también vale la pena mirar a Tenjin (los mismos creadores que los erubis)
Si utiliza Rails, la diferencia de rendimiento entre Haml y erubis es insignificante: las plantillas se compilan y almacenan en caché después del primer golpe, de todos modos. Combine esto con el almacenamiento en caché de fragmentos y páginas y puede estar seguro de que las vistas no son el cuello de botella de rendimiento de su aplicación.
La pregunta que debes hacerte es: ¿te gusta escribir Haml? ¿Te hace más productivo? Entonces puedes decidir más fácil.
Bueno, el rendimiento de Haml continúa mejorando con cada lanzamiento. ¿Está en un lugar aceptable en el momento actual? Eso es para que usted decida (estoy inclinado a decir "Sí", pero es su elección en función de sus necesidades). Si le gustan las plantillas y la legibilidad que ofrecen, entonces la caída en el rendimiento (aunque insignificante) debería ser realmente el factor final en su decisión.
Una de las otras herramientas que debería considerar usar en conjunto con Haml es make_resourceful, otra joya del encargado de mantenimiento de Haml (Nathan Weizenbaum) que simplifica muchas de las cosas RESTful en una aplicación de Rails.
Si tiene más preguntas más específicas sobre Haml (y m_r), estoy seguro de que Nathan estaría más que feliz de responderlas. Se puede contactar a través de Jabber / XMPP y correo electrónico. Su información de contacto se puede encontrar aquí .
Si le gusta cómo funciona haml desde el punto de vista de la codificación, no se preocupe demasiado por el rendimiento del motor de plantillas. (Aunque, como ha señalado, ahora es rápido). Definitivamente puede generar cualquier salida que los otros motores puedan.
En general, es más rentable invertir tu energía en configurar el almacenamiento en caché que preocuparte por tu motor de plantillas donde tienes problemas de rendimiento.
Me encanta HAML, ya que es una buena herramienta para escribir fácilmente HTML estructurado, y en general es simplemente una alegría de usar. Pero tiene muy poco que ver con elegir una herramienta en función de la cantidad de tráfico que pueda tener un sitio.
Si le preocupa el tráfico, debe preocuparse por usar el almacenamiento en caché correctamente. Y luego debe aplicar los principios del rendimiento general de la aplicación web: el resultado es que tendrá respuestas súper ágiles a la carga de la página. Que es lo que realmente necesita un sitio web de alto tráfico.
Un par de presentaciones que muestran cómo mejorar el rendimiento del sitio web se pueden encontrar aquí:
Michael Koziarski habla sobre el rendimiento de Rails en 2008 Paris on Rails
Jeremy Kemper habla sobre Performance on Rails en RailsConf EU''08
Y el mejor lugar que conozco para aprender a usar caché de los raíles correctamente es:
Haml rocas. No he visto números de rendimiento recientes, pero está bastante cerca de erb en estos días. Creo que podría ser más rápido que erb si activas el modo feo (lo que evita la sangría bonita). Estamos haciendo 2.8 millones de visitas de página por día con Haml.
Hay un benchmarker registrado en el árbol de fuentes de Haml: http://github.com/nex3/haml/tree/master/test
Actualización noviembre de 2009
Nathan (el desarrollador principal de Haml) publicó algunos benchmarks de Haml 2.2 en su blog. Puede ver los números exactos allí, en resumen:
- Modo normal (impresión bonita) = 2.8 veces más lento que ERB
- Modo feo (sin pestañas bonitas añadidas) = igual a ERB
Puede habilitar el modo feo colocando Haml::Template::options[:ugly] = true en un archivo de inicializador o de entorno. Tenga en cuenta que el modo feo no es realmente tan feo, el HTML resultante es en realidad mucho más bonito que ERB, simplemente no está muy sangrado.