Содержание
Для начала скажу что я очень большой любитель что-то попатчить и потвикать, даже если для этого нету особой необходимости. И вот недавно рассматривая статистику XCache на своем сервере я подумал что смог бы оптимизировать объем памяти который он тратит на опкеш (opcache) файлов различных фреймворков. Сделать это просто — переписать все используя только один, файлы которого были бы общими для всех сайтов, каких у меня порядка 20-ти, но в большинстве они довольно простенькие и особого труда их переписать мне бы не предоставило. И тут я начал поиск того самого фреймворка, который в идеале имел бы достаточно фич чтобы разработка была простой, и в тоже время был легким и быстрым. Вот те которые мне понравились и мои мысли о них.
Phalcon
Интересный в первую очередь тем что написан на С и компилируется как модуль для PHP. Судя по бенчмаркам работает намного быстрее других (где-то в 3 раза быстрее среднего) и при этом соблюдая достаточно привычную MVC структуру. Так же очень порадовало то, что Phalcon использует Dependency Injection и предоставляет свой DI контейнер, но вот судя по туторилам всё равно очень часто классы используются напрямую, при этом включая статические методы, чего лично я стараюсь избегать. К слову должен сказать что модуль скомпилировался и заработал с первого раза, без танцев с бубнами, что всегда приятно. Посмотрев немного глубже я начал видеть больше недостатков, во-первых не так уж много PHP программистов которые достаточно хорошо знают С чтобы помочь в его разработке, как следствие Phalcon будет развиватся медленнее его PHP собратьев. Во-вторых, в нем придумано много своих костылей, как например PHQL (Phalcon Query Language) на замену SQL и т.д. В итоге имеем достаточно смелый проект с неизвестным будущем.
PHPixie
О нем я услышал совсем недавно, его упомянул в своем твите Phil Sturgeon (разработчик PyroCMS и член PHP-FIG) и я сначала подумал что это попросту шутка. Серьёзно, я считаю что ни один PHP программист не сможет прослушать интро на главной странице до конца при этом не рассмеявшись. Философия PHPixie в том что фреймворк должен быть быстрым и легким как маленькая фея, этого разработчики пытаются достичь подходом известным питонистам как «Simple things should be simple, hard things should be possible». То есть компоненты PHPixie написаны так чтобы самым простым и быстрым способом справится с 90% рутинных задач при разработке сайтов, а оставшиеся 10% сложных более редких задач предполагается разработчик решит сам и незачем их включать в сам фреймворк. Должен сказать что в ни одном из моих сайтов не использовалось ничего такого чего не было бы в PHPixie, и даже Dependency Injection у них довольно хорош, хотя и склоняется в сторону Service Locator. В отличии от других реализаций DI контейнеров новые элементы добавляются в него посредством расширения класса, что менее гибко, но намного более прозрачно, при этом позволяет полностью избежать процедурного кода и получить распознавание класса элементов контейнера в IDE. Из минусов могу только отметить то, что воспринимать его серьёзно достаточно трудно, и вряд ли вы сможете убедить ваших сотрудников в офисе писать что-либо на фреймворке с феями и пони.
Fat-Free
Весь фреймворк одним файлом! Огромный плюс сразу на лицо: один файл с диска подгрузится быстрее чем множество, причём размер этого файла примерно 50 килобайт. Правда как оказалось в этом одном файле далеко не весь фреймворк, а только самая основная его часть, то есть если вам например понадобится доступ к базе данных то классы все равно придётся подргружать.Тем более тот же XCache и так кеширует PHP код, в таком случае выигрыш от такого подхода если и будет то очень небольшой. Вместе с фреймворком поставляется просто куча библиотек, что удобно если не использовать Composer и совсем не нужно если использовать. Также очень удивило то, что их ORM не поддерживает связей между таблицами, без каких его можно сразу выбросить в окно, так как это очень сильно сужает область его использования. Это фактически единственный из рассмотренных мною фреймворков, который меня действительно в себе разочаровал.
Silex,Slim и микрофреймворки.
Об этих двух известно и так достаточно много. Так как они оба не предоставляют полный стек для разработки тут все будет зависеть от того какие библиотеки вы к ним прикрутите и как это сделаете. Из этого исходит гибкость микрофреймворков, но с другой стороны труднее будет найти коммюнити и суппорт, так как у каждого программиста в итоге своя система. К тому же если фреймворк пишется весь одними людьми его намного проще освоить, так как философия кода похожа. А вот если у вас франкенштейн собранный из разных библиотек, в которых разный стиль и подход, то разобраться в этом будет сложнее. В конечном итоге попытки сделать из Silex полноценный фреймворк e у меня приводят к собранию некого подобия Symfony. Тут следует отметить что написания кода на Slim и Silex происходит интуитивно, быстро и безо всяких магий.
Lithium
Тут немного больше инноваций, например единое API для SQL и NoSQL баз данных, а также по словам разработчиков децентрализованная система фильтров. Фреймворк создан бывшим разработчиком CakePHP, и местами это очень даже заметно, как например при использовании моделей. Фильтры позволяют фактически перехватить вызов метода класса и на лету поменять его параметры и результат. Гибко, но в итоге можно получить макаронный код, наподобие того как работают плагины в WordPress. Так же удивительно что столь инновационный фреймворк так упорно использует статические методы. Радует простая архитектура, то есть если создавать простенький сайт то количество кода который придестя написать не намного отличается от использования Silex. В принципе очень хорошо подходит для тех кто работал с CakePHP в прошлом, но хочет попробовать что-то новое.
Так какой же я выбрал в итоге? В конце мой выбор стоял между Silex и PHPixie (да, я не устрашился фей) и в результате я все таки использовал их обеих. Большинство сайтов перевёл на Silex, а те которые писались на Kohana портировал на PHPixie, интерфейс которой чем-то к ней похож, особенно реализация ORM. Этим я смог уменьшить примерно в 6 раз количество памяти потребляемое XCache, ускорить генерацию страниц и даже успел немного порефакторить по дороге. В общем PHP — страна тысячи фреймоврков, так что думаю каждый сможет найти что-то по душе.
Yaf — это PHP микро-фреймворк, взявший за основу структуру приложения Zend Framework, но написанный на С и является PHP extension доступным через PECL
Основной (и единственной) задачей для написания его послужила необходимость максимально быстрой (сравнимой с php) обработки запросов в парадигме MVC но с удобством предоставляемым Zend Framework.
Yaf и Zend Framework, имеют аналогичные API и подобную концепцию, сохраняя при этом совместимость.
Я сгенерировал тестовое приложение (zf create project test) и провел небольшой синтетический тест производительности.
На картинке показан стандартный процесс диспетчеризации запроса в Yaf (ZF). Понятно что вся эта инфраструктура требует накладных расходов, и в случае ZF (не обработанного напильником) немалых:
ab -n1000
1. ZF:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 94 113 30.5 102 313
Waiting: 94 113 30.5 102 313
Total: 94 113 30.5 102 313
2. ZF + APC
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 36 40 6.2 39 111
Waiting: 36 40 6.2 39 111
Total: 36 40 6.2 39 111
3. YAF
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 1 2 0.8 2 15
Waiting: 1 2 0.8 2 15
Total: 2 2 0.8 2 15
4. PHP (html view)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 1 1 0.8 1 11
Waiting: 1 1 0.8 1 11
Total: 1 1 0.8 1 11
Понятно что скорость не основной показатель для выбора фреймворка, на когда Вы следующий раз решите написать facebook небольшое веб-приложение, обязательно обратите внимание на MVC парадигму в исполнении YAF(ZF).
