Что следует использовать для сайта с потенциально высоким трафиком: haml, erb или erubis?
Недавно я играл с Haml, и мне очень нравится, как выглядит полученный код ... разработчику. Я также не слишком беспокоюсь о том, что дизайнер сможет потреблять или изменять это ... мы небольшая команда.
Тем не менее, начало работы над проектом, по нашему мнению, вызовет довольно много трафика (а кто этого не делает?). Меня беспокоит, что есть вещи, которых я просто не знаю о хамле. Есть ли что-нибудь, что может сделать erb, чего не может сделать haml? Оказывает ли хамл негативное влияние на рост проекта? Есть ли другие вещи, которые следует учитывать?
И наконец ... как Хамл по скорости сравнивает с эрубисом? Я вижу, что теперь он якобы превосходит эрб и эруби ...
Спасибо!
С другой стороны, если вы беспокоитесь только о том, когда это становится проблемой, что вы будете делать, если решите, что ваш язык шаблонов слишком медленный, и вы застряли с множеством представлений, написанных на этом языке?
Хороший замечание, Кейси: шаблоны - это самая сложная часть веб-приложения для преобразования.
Ответы 7
Я бы лично порекомендовал нам erubis в предварительно скомпилированных шаблонах.
Особенно, если нет необходимости в динамическом создании шаблонов. Тогда ваше самое большое замедление будет ограничено скоростью, с которой рубин может анализировать рубин.
Я бы, вероятно, создал небольшое задание cron, которое просто отслеживает измененные исходные шаблоны и автоматически компилирует их при изменении, которые вы можете отключить, когда они не используются.
Скомпилируйте один раз, используйте много.
О, и если вас действительно беспокоит скорость, возможно, стоит взглянуть на Tenjin (те же создатели, что и erubis)
http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html
Вы знаете, как заставить Rails 3 использовать Tenjin?
Думаю, это полностью вопрос личных предпочтений и ремонтопригодности. Для меня Haml упрощает чтение и понимание шаблонов, а производительность очень приемлемая. В конце концов, язык шаблонов вряд ли станет тем местом, где вам нужно оптимизировать - скорее всего, запросы к базе данных, кэширование представлений или объектов и т. д.
Однако в случае шаблонов ERb вы получите лучшую производительность практически бесплатно, если будете использовать erubis.
Если вы используете Rails, разница в производительности между Haml и erubis незначительна: в любом случае шаблоны компилируются и кэшируются после первого обращения. Объедините это с кешированием фрагментов и страниц, и вы можете быть уверены, что представления не являются узким местом производительности вашего приложения.
Вы должны задать себе вопрос: нравится ли вам писать Haml? Это делает вас более продуктивным? Тогда вам будет проще решить.
Камни Хамла. Я не видел недавних показателей производительности, но в наши дни они довольно близки к erb. Я думаю, что это может быть быстрее, чем erb, если вы включите некрасивый режим (который предотвращает появление красивых отступов). Мы делаем 2,8 миллиона просмотров страниц в день с помощью Haml.
В дереве исходных текстов Haml есть тестер: http://github.com/nex3/haml/tree/master/test
Обновление ноябрь 2009 г.
Натан (главный разработчик Хэмла) опубликовал несколько тестов Haml 2.2 в своем блоге. Здесь вы можете увидеть точные цифры, но вкратце:
- Нормальный (приятная печать) режим = в 2,8 раза медленнее, чем ERB
- Уродливый режим (без красивых вкладок) = равно ERB
Вы можете включить уродливый режим, поместив Haml::Template::options[:ugly] = true в инициализатор или файл среды. Обратите внимание, что уродливый режим на самом деле не такой уродливый - полученный HTML на самом деле намного красивее, чем ERB - он просто не имеет хорошего отступа.
ваше количество и предоставленные тесты впечатляют. А про некрасивый режим приятно знать :)
Нет необходимости устанавливать режим ugly для производства в инициализаторе, потому что HAML включает этот режим в производстве по умолчанию.
Что ж, производительность Haml продолжает улучшаться с каждым выпуском. Находится ли он в приемлемом месте в настоящее время? Это вам решать (я склонен сказать «да», но это ваш выбор, исходя из ваших потребностей). Если вам нравятся шаблоны и удобочитаемость, которые они обеспечивают, то падение производительности (пусть и незначительное) действительно должно стать последним фактором в вашем решении.
Один из других инструментов, который вам следует рассмотреть в сочетании с Haml, - make_resourceful, еще одна жемчужина, разработанная разработчиком Haml (Натан Вайзенбаум), которая упрощает многие вещи RESTful в приложении Rails.
Если у вас есть дополнительные, более конкретные вопросы о Хэмле (и m_r), я уверен, что Натан будет более чем счастлив ответить на них. С ним можно связаться через Jabber / XMPP и по электронной почте. Его контактную информацию можно найти здесь.
Если вам нравится, как работает haml с точки зрения кодирования, не беспокойтесь о производительности движка шаблонов. (Хотя, как вы отметили, теперь он работает быстро.) Он определенно может генерировать любой выходной сигнал, который могут получить другие движки.
Как правило, выгоднее тратить силы на настройку кеширования, чем беспокоиться о своем движке шаблонов, где у вас возникают проблемы с производительностью.
Мне нравится HAML, потому что это хороший инструмент для простого написания структурированного HTML, и в целом его просто приятно использовать. Но это очень мало связано с выбором инструмента в зависимости от объема трафика, который может иметь сайт.
Если вас беспокоит трафик, вам следует позаботиться о правильном использовании кеширования. А затем вам нужно применить принципы общей производительности веб-приложений - в результате вы получите супер-быструю реакцию на загрузку страницы. Это то, что действительно нужно сайту с высокой посещаемостью.
Здесь можно найти пару презентаций, которые показывают, как повысить производительность веб-сайта:
И лучшее место, которое я знаю, чтобы научиться правильно использовать кеширование рельсов, это:
Лично я бы стал беспокоиться о масштабируемости, когда это станет проблемой. В конце концов, база данных занимает больше всего времени по сравнению с визуализацией представления. (По крайней мере, насколько я видел.)