Должен ли я использовать haml, erb или erubis для сайта с потенциально высоким трафиком?
Я недавно играл с Haml, и мне очень нравится, как итоговый код выглядит для меня... для разработчика. Я также не слишком беспокоюсь о том, что дизайнер сможет потреблять или менять его... мы небольшая команда.
Тем не менее, начало работы над проектом, который, по нашему мнению, будет генерировать довольно мало трафика (а кто нет?). Я обеспокоен тем, что есть вещи, которые я просто не знаю о хамле. Есть ли что-нибудь, что может сделать эрб, чего не может хамл? Оказывает ли хамл отрицательный эффект по мере роста проекта? Есть ли другие вещи, которые следует учитывать?
И наконец... как Хамл сравнивается по скорости с эрубисом? Я вижу, что теперь якобы бьет эрб и эруби...
Спасибо!
7 ответов
Хамл рулит. Я не видел каких-либо недавних показателей производительности, но это очень близко к эрб в наши дни. Я думаю, что это может быть быстрее, чем erb, если вы включите уродливый режим (который предотвращает красивые отступы). Мы выполняем 2,8 миллиона просмотров страниц в день с Haml.
В дереве исходных текстов Haml проверен бенчмаркер: http://github.com/nex3/haml/tree/master/test
Обновление ноябрь 2009
Натан (главный разработчик Haml) опубликовал несколько тестов Haml 2.2 в своем блоге. Вы можете увидеть точные цифры там, но вкратце:
- Нормальный (симпатичная печать) режим = в 2,8 раза медленнее, чем ERB
- Гадкий режим (без красивых вкладок) = равно ERB
Вы можете включить уродливый режим, поместив Haml::Template::options[:ugly] = true в файле инициализатора или окружения. Обратите внимание, что уродливый режим на самом деле не такой уродливый - итоговый HTML на самом деле намного красивее, чем ERB, - он просто не имеет хороших отступов.
Если вы используете Rails, разница в производительности между Haml и erubis незначительна: шаблоны в любом случае компилируются и кэшируются после первого попадания. Объедините это с кэшированием фрагментов и страниц, и вы можете быть уверены, что представления не являются узким местом производительности вашего приложения.
Вопрос, который вы должны задать себе: вам нравится писать Haml? Это делает вас более продуктивным? Тогда вы можете решить проще.
Я люблю HAML, так как это хороший инструмент для простого написания структурированного HTML, и в целом это просто удовольствие для использования. Но это очень мало связано с выбором инструмента в зависимости от объема трафика, который может иметь сайт.
Если вы беспокоитесь о трафике, вам следует правильно использовать кеширование. А затем вам нужно применить принципы общей производительности веб-приложений - в результате вы получите очень быстрые ответы на загрузку страниц. Что действительно нужно для сайта с большим трафиком.
Несколько презентаций, которые показывают, как улучшить производительность сайта, можно найти здесь:
Майкл Козярский рассказывает о выступлении на Rails в 2008 году в Париже на Rails
Джереми Кемпер рассказывает о производительности на Rails на RailsConf EU'08
И лучшее место, где я знаю, чтобы научиться правильно использовать кэширование рельсов:
Я думаю, что это полностью вопрос личных предпочтений и ремонтопригодности. Для меня Haml облегчает чтение и понимание шаблонов, а производительность очень приемлема. В конце концов, язык шаблонов вряд ли будет тем местом, где вам нужно оптимизировать - скорее всего, запросы к базе данных, представление или кэширование объектов и т. Д.
Однако, в случае шаблонов ERb, вы получите лучшую производительность по существу бесплатно, если будете использовать erubis.
Если вам нравится, как работает haml с точки зрения кодирования, не стоит слишком беспокоиться о производительности движка шаблонов. (Хотя, как вы указали, теперь это быстро.) Он может определенно генерировать любые выходные данные, которые могут другие движки.
Как правило, более выгодно направить свою энергию на настройку кэширования, чем беспокоиться о своем движке шаблонов, где у вас возникают проблемы с производительностью.
Я бы лично порекомендовал нам erubis в скомпилированных шаблонах.
Особенно, если нет необходимости в динамических шаблонах. Тогда ваше самое большое замедление будет ограничено скоростью, с которой рубин может анализировать рубин.
Я бы, вероятно, настроил небольшую работу cron, которая просто следит за измененными исходными шаблонами и автоматически компилирует их при изменениях, которые можно отключить, когда они не используются.
Скомпилируйте один раз, используйте много.
О, и если вы действительно беспокоитесь о скорости, возможно, Тенджин тоже стоит посмотреть
Что ж, производительность Haml продолжает улучшаться с каждым выпуском. Это в приемлемом месте в настоящее время? Это вам решать (я склонен сказать "да", но это ваш выбор, основанный на ваших потребностях). Если вам нравятся шаблоны и удобочитаемость, которую они предоставляют, то снижение производительности (хотя и незначительное) действительно должно быть последним фактором в вашем решении.
Одним из других инструментов, которые вы должны рассмотреть в сочетании с Haml, является make_resourceful, еще одна жемчужина сопровождающего Haml (Натана Вейзенбаума), которая упрощает многие вещи RESTful в приложении Rails.
Если у вас есть еще какие-то более конкретные вопросы о Хэмле (и м_р), я уверен, что Натан был бы более чем рад ответить на них. С ним можно связаться через Jabber/XMPP и электронную почту. Его контактную информацию можно найти здесь.