<ctpp/> главная .:. скачать .:. документация .:. faq .:. разработчикам  
o Главная
    Скачать!
    Установка

o Помощь
    Что такое CTPP?
    Как работает CTPP?
    Онлайн-документация
    FAQ

o В действии
    Проекты
    Первые шаги
    Как сделать?..
    Разработчикам

o В разработке
    Тесты производительности
    Расписание
    Разработчики

    Благодарности




MVC в высоконагруженных проектах

Классический подход

Как известно, в классической модели MVC есть три основных сущности: набор моделей, контроллер моделей и представление данных.

Наиболее ортодоксальные реализации полностью изолируют эти сущности друг от друга: считается, что в представлении никакие данные не обрабатываются, а происходит только наложение полученной объектной модели на шаблон, Контроллер используется только для указания списка выполняемых моделей, а внутри моделей формируется исключительно абстрактный набор данных.

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

С ростом нагрузки на систему, накладные расходы на коммуникацию между уровнями абстракции все увеличиваются и наступает момент, когда классическая модель MVC перестает работать. По крайней мере, перестает работать без качественного увеличения мощности вычислительной системы. Зачастую в высоконагруженных проектах увеличение вычислительной мощности на 20-30% означает покупку нескольких десятков компьютеров. Очевидно, что подобный подход ущербен.

Как изменить ситуацию?

Давайте откажемся от MVC и разработаем монолитный проект, где формирование данных производится по мере необходимости в месте, где эти данные выводятся.
Какие плюсы у этого решения?
- Безусловно высокая скорость работы полученной системы.
- Возможность быстрого проведения исправлений в коде.

Однако, есть и минусы:
- Сложность поддержки проекта в целом
- Проблемы при повторном использовании кода
- Сложность изменения функционала, особенно - при смене дизайна проекта или изменении бизнес-логики работы

Для больших проектов это не приемлемо. Давайте тогда попробуем не отказаться от модели MVC, а доработать ее таким образом, чтобы часть информации обрабатывалась в представлении. Иными словами, чтобы основной набор данных по-прежнему обрабатывался набором моделей, а окончательная подготовка к выводу производилась в специальном блоке - процессоре данных.

Под окончательной обработкой мы подразумеваем такие действия с данными, которые существенно не изменяют общий их набор. Например, форматирование строки даты из unix timestamp, вывод локализованных сообщений для мультиязычных проектов или разннобразные логические действия вида ЕСЛИ условие ТО вывести_блок1 ИНАЧЕ вывести_блок2 КОНЕЦ_ЕСЛИ.

Подобный подход позволяет сильно упростить как код моделей, так и код контроллера, а также - достичь более ровного рапределения нагрузки по компонентам системы.

Сведем полученные требования воедино. Итак, мы выносим в функционал представления обработку данных, что дает нам возможность собрать этот функционал воедино; мы можем реализовать простую обработку данных очень быстро, а также - перераспределить нагрузку между моделями и представлением.

Дополнительные пожелания - наличие интерфейсов к популярным языкам программирования, простое API для написания функций обработки данных, кроссплатформенность системы.

CTPP - оптимальный вариант

В качестве визуализатора, отвечающего всем этим требованиям мы используем библиотеку CTPP - высокопроизводительное открытое решение, разработанное на языке C++. Это push-шаблонизатор с программными интерфейами для Perl, PHP и Python; первые два уже активно используются в ряде проектов, а модуль для python находится в альфа-тестировании и готовится к скорому выпуску.

Архитектура шаблонизатора представлена на рисунке и состоит из четырех подсистем: компилятора шаблонов, который переводит текст шаблона страницы в байт-код, виртуальной машины, исполняющей байт, системы кэширования шаблонов и библиотеки функций процессора данных.

Почему была выбрана архитектура с виртуальной машиной и компилятором? Дело в том, что при таком подходе можно реализовать часть кода раз и навсегда и при регулярном усложнении синтаксиса шаблонов не пересобирать библиотеку. Вдобавок, откомпилированный исполняемый код требует только того набора объектов в памяти, что необходимы для работы.

Тесты

Результаты тестирования поученной библиотеки удивили даже нас: в 25 - 30 раз быстрее Template::Toolkit, в пять раз быстрее HTML::Template::Pro и в два раза быстрее HTML::Template::JIT.

Тесты производительности в сравнении с другими библиотеками приведены ниже.
Template Toolkit    = 2.878 (25.2)
HTML::Template      = 2.682 (23.1)
HTML::Template::Pro = 0.596 (5.1)
HTML::CTPP2         = 0.116 (1)

Что дальше?

Разумеется, на будущее запланирована поддержка и развитие этой замечательной библиотеки. В ближайших планах:
- поддержка разных синтаксисов шаблонов
- введение ЭЦП шаблонов для повышения уровня безопасности системы
- компиляция в исполняемый двоичный код, для еще большего повышения производительности
- дополнительное развитие системы функций и предоставление в открытый доступ используемых в наших проектах
- реализация программных интерфейсов для языков Java и Ruby
- поддержка платформы Windows


Copyright © 2003 - 2008 CTPP Dev Team.