Главная

Facebook XHP. Объектный шаблонизатор

2014-07-15 в 13:21, admin, рубрики: Facebook, hacklang, HHVM, php, Веб-разработка, шаблонизатор

Несмотря на то, что Facebook анонсировал XHP еще в феврале 2010 года, до сих пор об этом шаблонизаторе очень мало информации, хотя даже как идея XHP весьма и весьма интересен.

В этой статье я попытаюсь дать краткий обзор XHP, основные плюсы и минусы, а также затрону вопросы производительности.

XHP — это расширение PHP, которое дополняет синтаксис языка, с одной стороны улучшая воспринимаемость front-end кода и с другой — помогая избегать XSS-атак. [1]

Итак, что нам нужно, чтобы вывести немножко HTML(XML)-разметки?

Если грубо, то потребуется следующее:

// генерируем HTML
$html = '<div id="mydiv"><p>Привет!</p></div>';
echo $html;

Теперь то же самое, используя XHP:

$html = <div id="mydiv"><p>Привет!</p></div>;
echo $html;

или так:

$html = new :div(array('id'=>'mydiv',), new :p(array(), 'Привет!'));
echo $html;

Думаю, что после данных примеров, большинству уже стало понятно, что «XML» транслируется расширением XHP в некие классы, которые описывают html-element.
В этом по большему счету и есть вся суть XHP-шаблонизатора. Теперь вы не работаете со «строковым HTML». От слова «совсем», поскольку каждая нода -это некий объект со своими свойствами.

Дополнительно ко всему, любой пользовательский контент экранируется, т.е. для любой дочерний элемент, не являющийся html-element автоматически обрабатывается htmlspecialchars. Да, и ваш контент, полученный из базы данных, тоже будет по умолчанию экранирован, поверьте, так лучше для вас.

PHP:

$html = "<div>{$_POST['xss_content']}</div>"; // не безопасно

XHP:

$html = <div>{$_POST['xss_content']}</div>; // безопасно

Ещё одна фича, исходящая из природы XHP — это встроенная валидация HTML(XML). Вы же не можете проинстанцировать класс таким способом:

$html = new myHtml(;

Значит и оставить не закрытые, с неправильной вложенностью html-element'ы не сможете (short tags поддерживаются).

Теперь о минусах

Единственным очевидным минусом вышеописанной схемы является то, из чего проистекают её плюсы — каждый элемент — это объект.
Соответственно layout из 2000 вложенных тэгов — это 2000 вложенных объектов.

Что мы получим на выходе ясно:

Повышенный расход памяти
Снижения быстродействия

Повышенный расход памяти затрагивать особого смысла в рамках данной статьи не вижу, т.к. XHP-объекты достаточно простые, а памяти под процесс выделяется достаточно много ( 640 килобайт хватит всем (с) ).
Но создание множества вложенных объектов и преобразование XHP-разметки в объекты должно увеличить время рендеринга. Вопрос — на сколько?

К счастью, некто Расмус Лердорф еще в 2010 году провел сравнительный анализ «скорострельности» XHP vs PHP native и получил следующие результаты [2]:

PHP: деградация ~97% (30 rps — 1300 rps)
PHP+APC: деградация ~75% (330rps — 1460 rps)

Поскольку ~~это было давно и неправда~~ тесты получились несколько синтетические — генерировался мизерный фрагмент HTML (форма), я решил, что нужно провести сравнительные тесты на HHVM (в которую поддержка XHP встроена «из коробки», для PHP придется собирать отдельный модуль).

К сожалению, описание всех XHP-классов так и осталось в php-файлах (Расмус писал, что возможно проблему низкой производительности можно частично нигилировать переносом объявлений базовых классов в скомпилированный модуль), для Hack авторы предлагают лишь заменить <?php на <?hh //decl, поэтому надежда была только на сам XHP-парсер разметки.

И, естественно, для рендеринга я взял не 4-5 тэгов, а полноценный Layout. Настройки siege аналогичны тем, что в примере у Расмуса.

HHVM + XHP

siege -c 3 -b -t30s http://****.ru
Transactions:                   6003 hits
Availability:                 100.00 %
Elapsed time:                  29.54 secs
Data transferred:               8.80 MB
Response time:                  0.01 secs
Transaction rate:             203.22 trans/sec
Throughput:                     0.30 MB/sec
Concurrency:                    3.00
Successful transactions:        6003
Failed transactions:               0
Longest transaction:            0.03
Shortest transaction:           0.00

HHVM + PHP

siege -c 3 -b -t30s http://****.ru
Transactions:                  19583 hits
Availability:                 100.00 %
Elapsed time:                  29.96 secs
Data transferred:              33.22 MB
Response time:                  0.00 secs
Transaction rate:             653.64 trans/sec
Throughput:                     1.11 MB/sec
Concurrency:                    2.99
Successful transactions:       19583
Failed transactions:               0
Longest transaction:            0.02
Shortest transaction:           0.00

Деградация около 68%. Лучше, чем 75%, но всё равно относительно много.
Почему «относительно»? Потому что тестовое «приложение» состояло только из View, без обращения к БД, без бизнес-логики и прочего.
В реальности же может получиться, что деградация производительности на этапе рендеринга View в процентном соотношении будет ничтожной на фоне остальной части приложения.

В конце-концов вопрос выбора того или иного шаблонизатора остаётся за архитектором системы.

Информация для ознакомления: