0,0
рейтинг
19 ноября 2012 в 18:45

Разработка → Phalcon — скомпилированный PHP MVC Framework tutorial

PHP*

Создание скомпилированных MVC фреймворков для PHP не раз приходила на ум кодерам.

Достоинства такого подхода:
  • Высокая производительность
  • Малая нагрузка файловой системы
  • Меньший расход памяти (при строгой типизированности)
  • Частичная обработка данных без интерпритации

И само собой не менее явные недостатки:
  • Если Вы не знаете C, то Вы полностью зависите от разработчиков
  • Проект может в любую секунду сдуться
  • В зависимости от архитектуры, часть модулей все равно приходится писать самому, что уменьшает выигрыш



В этой статье я попытаюсь познакомить с еще одной попыткой сделать скомпилированный PHP MVC Framework.

Знакомство


Сам я в поисках быстрого, надежного и способного фреймворка. Гуляя по зарубежным форумам и блогам, наткнулся на интересный бенчмарк, где некий фреймворк на «Hello World!» уделывал пузатых знаменитостей в несколько раз.



Пройти мимо такого я не смог и принялся узнавать, как это работает и развивается.
Проекту менее года. Первый коммит на github — 10 января 2012. И да, это open source проект. Насколько я понял, сейчас им более менее активно занимаются 3 человека.

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

Пример

Лучший способ изучить framework — сделать что-нибудь на нем, параллельно изучая документацию.
Я сделал 3-х страничное приложение, показывающее некоторые возможности phalcon, а именно:
  • Роутинг
  • Работа с БД, на внутреннем языке PHQL
  • Работа с events
  • Фильтрация данных
  • Кеширование
  • DI (dependency injection)
  • Возможности встроенного движка шаблонов Volt

Кроме того, разработчики заявляют гораздо большее:
  • ODM — работа с документо-ориентированными БД
  • Многоязычность
  • Автоматическое создание приложений CRUD из консоли или веб-морды
  • Поддержка нескольких популярных движков шаблонов
  • Микро приложения (для создания REST API)
  • Создание логгера любой конфигурации
  • Создание своего event manager с fire и catch
  • Встроенный обработчик html тегов для шаблонов
  • Поддержка nemespace и мульти-модульности
  • Обработка сессий и flash сообщений
  • ACL


Иерархия проекта:

xmpl/
    apps/
        app/config/
        app/controllers/
        app/models/
        app/views/
        app/My/
    public/
        public/img/
        public/css/
        public/js/


Весь код будет лежать по пути /apps/, инициализация приложения /public/index.php. На последний файл собственно и нужно настроить редирект несуществующих страниц, через apache (.htaccess в папках / и /public/ ) или nginx.

Инициализация:

Про инициализацию вкратце под спойлером.
<?php

//загружаем конфигурационные данные из ini файла
$config = new Phalcon\Config\Adapter\Ini( '../apps/config/config.ini' );

//Подключаем загрузчик, показывая ему, где будут лежать вызываемые классы
$loader = new \Phalcon\Loader();
$loader->registerDirs(array(
	$config->application->controllersDir,
	$config->application->modelsDir,
	$config->application->myDir,
));
$loader->register();

//Подкючаем DI
$di = new \Phalcon\DI();

//Компонент, отвечающий за обработку url.
$di->set('url', function() use ($config){
	$url = new \Phalcon\Mvc\Url();
	return $url;
});

//Подключаем модель соединения с БД, доступны ( Mysql, PostgreSQL, SQLite)
$di->set('db', function() use ($config) {
    $connection = new \Phalcon\Db\Adapter\Pdo\Mysql(array(
        "host" => $config->database->host,
        "username" => $config->database->username,
        "password" => $config->database->password,
        "dbname" => $config->database->name
    ));

    return $connection;
});

//2 вспомогательных компонента для работы с БД
$di->set('modelsManager', function(){
	return new Phalcon\Mvc\Model\Manager();
});
//Указываем, где хранится мета-данным из БД, доступны (Apc, Files, Memory, Session)
$di->set('modelsMetadata', function(){
	return new \Phalcon\Mvc\Model\Metadata\Memory();
});

//Подключаем роутер
$di->set('router', 'Phalcon\Mvc\Router');	

//Подключаем диспетчер, чтобы иметь доступ к методам view из контроллера. Можно назначить свой обработчик.
$di->set('dispatcher', function() use ($di) {
	$dispatcher = new Phalcon\Mvc\Dispatcher();
	return $dispatcher;
});

//Обработка ответов и запросов
$di->set('response', 'Phalcon\Http\Response');
$di->set('request', 'Phalcon\Http\Request');

//Подключение фильтра данных
$di->set('filter', function(){
    return new \Phalcon\Filter();
});

//Подключаем сервис внутреннего движка Volt с настройками
$di->set('voltService', function($view, $di) use ($config) {
    $volt = new Phalcon\Mvc\View\Engine\Volt($view, $di);
    $volt->setOptions(array(
        "compiledPath" => $config->application->templCompDir,
        "compiledExtension" => ".compiled"
    ));
    return $volt;
});

//Подключаем компонент, отвечающий за вид. Также назначаем уме eventManager, 
//который, получает несколько событий выбрасываемых view. Таким образом мы 
//можем манипулировать с шаблонами как захотим
$di->set('view', function() use ($config) {

    $eventsManager = new \Phalcon\Events\Manager();
    $viewManager = new ViewManager();
    $eventsManager->attach('view', $viewManager);

    $view = new \Phalcon\Mvc\View();
    $view->setViewsDir( $config->application->viewsDir );
    $view->registerEngines(array(
    	".phtml" => 'voltService'
    ));

    $view->setEventsManager($eventsManager);

    return $view;
});

//Подключаем фронт и бакенд кеширование, доступны front (Base64, Data, None, Output) и backend (Apc, File, Memcache, Mongo), само собой, можно дописать и свои
$di->set('cache', function(){

    $frontCache = new Phalcon\Cache\Frontend\Data(array(
        "lifetime" => 60
    ));

    $cache = new Phalcon\Cache\Backend\Apc($frontCache);
    return $cache;
});


//собственно инициализация и вывод ошибок как есть на экран
try {
	$application = new \Phalcon\Mvc\Application();
	$application->setDI($di);
	echo $application->handle()->getContent();
}
catch(Phalcon\Exception $e){
	echo $e->getMessage();
}



Большую часть можно подключить автоматически, вот так:
$di = new Phalcon\DI\FactoryDefault();


Контроллеры и свои классы:

Теперь, в Вашем приложении доступен стандартный роутинг /baseUri/ControllerName/ActionName/, подключены методы, которые через di наследуют контроллеры $this->cache, $this->dispatcher, $this->db

Также Вы можете вызывать свои классы, находящиеся в папке /apps/My/
Класс ViewManager получит все события, генерируемые View. На интересует beforeRender. В нем, мы передадим в вид переменные, содержащие название класса и действия.

Также мы создадим класс BaseController
class BaseController extends \Phalcon\Mvc\Controller
{
	public function initialize()
    {
        Phalcon\Tag::prependTitle('Example | ');
    }
}

class IndexController extends BaseController {

	public function initialize()
    {
        //Устанавливаем текст в тег title, также можно добавлять постфикс (сделано в контроллере Poll)
        Phalcon\Tag::setTitle('Index');
        parent::initialize();
    }

    public function indexAction(){

    }
}


Он наследует стандартный класс. Наши контроллеры, будут уже наследовать BaseController и получать префикс к html тегу title.


View

Phalcon предоставляет довольно удобный метод шаблонов, где существует иерархия.
Шаблоны хранятся в папке /apps/views/
Корневой шаблон /apps/views/index.phtm рендерится всеми контроллерами, кроме тех, где явно задан другой путь.
Этот файл может содержать в себе дальнейший путь иерархии:
{{ content() }}


Я использовал синтаксис встроенного движка шаблонов. Для других движков тоже есть свои аналоги.
Эта функция вызывает следующий шаблон, расположенный по пути:
/apps/view/layer/ControllerName.phtml

По сути, задавая особое оформление для определенного контроллера, как я и сделал в своем приложении. В нем также можно вызвать content(), тем самым подгрузив шаблон /apps/views/ControllerName/ActionName.phtml

В шаблонах можно подгружать другие шаблоны, заменять предустановленные блоки, вызывать пользовательские и предопределенные движком функции, обращаться к методам Models.
Только Volt их молодой проект, поэтому многих функций в нем нет, но они запланированы на ближайшие релизы.
Из коробки, поддерживают Slim, Smarty, Mustache

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

Модели

Подключение к БД, осуществляется с помощью PDO. Имеется 2 реализации работы с базой данных, объектно-ориентированный путь и PHQL, свой обработчик псевдо SQL строк.
К сожалению, первый подходит только для довольно простых запросов, а второй будет сложным, для тех, кто привык к первому.

Модель в приложении
class Poll extends Phalcon\Mvc\Model
{
    //объявление используемых переменных в строках, явное указание, какие доступны напрямую public
    public $id;
    public $gender;
    public $age;
    public $read_modern;
    public $authors;
    public $genre;
    public $method;
    public $timestamp;

    //метод вызывается при инициализации БД, должен возвращать имя используемой таблицы
    public function getSource()
    {
        return 'answers';
    }

    //выбор метода соединения при инициализации
    public function initialize()
    {
        $this->setConnectionService('db');
    }
}



В моделях, для себя, ничего нового и интересного не нашел, разве что хранение мета данных в разных местах. Также их можно полностью предопределить.

Недостатки

Я не до конца разобрался во всем, что может этот фреймворк, но все же заметил недостатки:
  • У меня так и не получилось собрать dll под windows. Разработчики так и не ответили.
  • На vps не смог собрать версию 0.6.1, сообщал разработчикам, так и не смогли разобраться.
  • Не нашел способа настроить роутинг для статичного файла example.com/tp/score.json Файла нет — роутер к контроллеру и методу, иначе статичный файл. Буду разбираться.
  • Очень мало возможностей у встроенного шаблонизатора Volt.
  • Не нашел способа вывода Flash сообщений без использования сессий, не отключая рендеринг.
  • Сильно разбитая документации по моделям — 3 отдельных раздела, нет структурности.
  • В большинстве случаев невозможно использовать на shared хостингах.

Трудно назвать это недостатками. Разве что нет прямого общения с разработчиками, кроме issue list на гитхабе.

Функционал приложения


Имеем приложение с главной страницей, страницей опроса и вывода результатов. Отсюда работа с БД, отправка данных с фильтрацией, и получение с минутным кешированием в Apc.

Железо: VPS хостинг. Процессор х1 500 МГц, ОП 256 Мб. Лошадка слабая.
Подключен APC. Настройки все дефолтные. Сервер: Nginx — PHP-FPM — PHP — MySQL

Синтетические тесты:
1. -c50 -d5 -r10
2. -c100 -d2 -r10
3. -c300 -d2 -r20 (LA — 0.7)
4. -c400 -d1 -r20 (LA — 0.47)
5. -c800 -d1 -r30 (LA — 1.1)
6. -c1000 -b -r20 (LA — 2)
(-с: конкуренты, -d: задержка перед повторным вызовом, -r: количество повторений, -b: вызов без задержки, LA: load average)


Siege делает в рандомном порядке 3 запроса, все динамические. 2 из них с запросами к БД, с кешированием в 1 минуту.
При большой конкурентности появились ошибки (до 2% запросов).
Максимально обрабатывал 516 запросов в секунду. Довольно недурно. Если хранить запрашиваемые json в файлах и обновлять их по cron, то можно нагрузку в разы сократить.

Провел еще пару тестов с siege. -c500 -r10 -d1 -i
1. APC отключен
2. APC включен с маленьким буфером и stat=0
image

Ссылки


Сайт Phalcon
Репозиторий Phalcon

Работающий пример
Исходники примера на GitHub

P.S.

Опрос в приложении не просто так выбран, пожалуйста, отвечайте честно ;)
И извиняюсь за сумбур, в одной статье выложить все невозможно.

19.11.2012 23:00
Кто-то решил заддосить по запросу, возвращающему результаты с БД. Логи растут как на дрожжях. LA колеблется от 1 до 4. Сайт грузится. Я очень рад :)
Ддосят при помощи wrk. Судя по логам доходит до 60 запросов в секунду. ip 188.254.105.18
19.11.2012 23:43
Наспамил мне 0.5ГБ лог и хватит. Пока ддос.
Спартак Каграманян @Assorium
карма
37,0
рейтинг 0,0
Пользователь

Похожие публикации

Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (100)

  • +2
    Довольно приятный фреймворк. Но на шаред хостингах его не заюзаешь.
    • 0
      Когда писал недостатки, этот вариант крутился в голове. Спасибо, что напомнили.
      Да, к сожалению это проблема.
    • +4
      >И на шаред хостинги его не поставишь.

      Думаю это не разу не проблема.
      Учитывая что на Шаред/Виртуал хостинги устанавливаются сайты, которые не должны блистать скоростями на высоких нагрузках.

      А если пишется крупный проект, с бешеным онлайном и клиент платит бешеные деньги за повышенную скорость работы сайта, именно программистам? Я бы взял такой инструмент, сразу мы экономим время (а значит и деньги) на скорости разработки и выполняем условие заказчика.
      • –1
        Этот инструмент экономит время еще и благодаря этому.
        Я мельком упомянул инструменты разработчика. Они позволяют создать каркас и полную внутреннюю структуру для пустого приложения.
  • +4
    «Phalcon — самый быстрый PHP MVC Framework».
    Мне кажется, что обращать внимание в заголовке на один из качеств фрймверка не корректно.
    Зачем мы используем фреймверки? Для того чтобы облегчить рутинные операции (для того чтобы посадить еще менее грамотного программиста), мы задумываемся прежде всего об удобстве и простоте использования инструмента и уже потом о скорости, оптимизациях.
    Быстрый не значит удобный и простой.
    Например, почему популярен язык Java, хотя по скорости далеко не самый быстрый инструмент?
    • –1
      Признаю, заголовок желтый. Но именно такой заголовок и привлек мое внимание в зарубежных блогах.
      Все зависит от задач и возможностей. Имея 256 RAM, удобные фреймворки могут съесть всю память на паре клиентов.
      А если фреймворк и удобный и быстрый, то это золотая жила. Я бы оценил phalcon в виду его молодости ( 0.6.1 ) на 4.5/5
      • –2
        Имея 256 RAM, удобные фреймворки могут съесть всю память на паре клиентов.

        Врете вы всё. Вы реально упирались в производительность php в ваших веб-приложениях?
        • 0
          С чего взяли, что вру? У меня работающий клиент, который выдерживал более 70000 одновременных запросов на Zend. Выдержал, только благодаря мощной тачке и разумной настройке.
          Этот же клиент уложил на лопатки мой локальный компьютер, при подключении к нему около 10 пользователей (там частота вызовов гораздо больше, но все же).
          Попробуйте представить сколько памяти ест Zend. Попробуйте представить сколько памяти ест Zend с включенным APC.
          Прямо сейчас меня ддосят. Ничего не предпринимаю. Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД. LA доходит до 6. Память почти на нуле. Но сайт ни разу не упал. Более чем уверен, тот же сайт но на Zend уже давно бы валялся.
          • +4
            У меня работающий клиент, который выдерживал более 70000 одновременных запросов на Zend

            70 тысяч запросов на Zend это что значит? 70k req/sec? 70k req/day?

            Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.

            60 запросов в секунду это не DDOS :)

            к скрипту с 12 запросами к БД.

            Сколько миллионов записей на таблицу, какой характер запросов — write/read? Какая репликация / может у вас шардинг?

            Более чем уверен, тот же сайт но на Zend уже давно бы валялся.

            Вы зря так уверены :) Вопрос ведь не в интерпритаторе php. Ну включили APC, не гоняет теперь байткод каждый раз. А вот к БД нужно открыть коннект, закрыть коннект, прочитать что-то, записать что-то.

            Я не к тому, что фреймворк — «плохо, плохо, руки прочь», я к тому, что вы как-то уж больно много нагрузки вкладываете в роутинг и десяток классов фреймворка. Что ZF, что yii.
          • +1
            60 rps из которых 12 rps к базе вы называете DDOS'ом?

            Ок.

            А то у меня 187 rps к базе, и я всегда считал, что это — штатная ситуация. Буду знать, что меня дидосят, да. Все, кидаюсь менять Invision Powerboard (говоно еще то) на Phalcon!
            • 0
              60 rps только с одного ip, во-первых
              каждый из запросов создает от 1 до 12 запросов к бд, во-вторых
              у меня очень маленький и слабый сервер, в-третьих

              Invision Powerboard

              Мне кажется, что Вы путаете понятия CMS и Framework
              • –2
                > 60 rps только с одного ip, во-первых

                Других цифр озвучено не было:

                Прямо сейчас меня ддосят. Ничего не предпринимаю. Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.

                > у меня очень маленький и слабый сервер

                Это нам тоже неизвестно.

                > Мне кажется, что Вы путаете понятия CMS и Framework

                Я не путаю. Это была ирония
                • –1
                  Железо: VPS хостинг. Процессор х1 500 МГц, ОП 256 Мб. Лошадка слабая.

                  Сначала пишу, потом читаю?
                  • 0
                    Даже с таким железом 60 rps — это не DDOS.
  • 0
    Почему бы не поставить APC вместо всего этого?
    • +2
      А как вы собрались использовать APC вместо фреймворка? Расскажите.
      • +5
        Benchmark измеряет количество файлов, скорость парсинга и прочие иррелевантные свойства. Поставьте APC, потом сравнивайте.
        • –1
          APC потребляет очень много памяти, если его прикрутить на тот же Zend. В нашем проекте он ест почти 8ГБ RAM.
          И у меня APC включен, в нем хранится кеш запросов к БД и шаблоны.
    • 0
      Phalcon будет в несколько раз быстрее любого фреймворка даже с APC.
      Вы же не будете утверждать, что код на C и код на PHP c APC работает одинаково быстро?

      А когда дело касается монстров типа симфони2 и зенд2, то это как небо и земля.
      • 0
        Если судить по тестам то Phalcon не нас только быстр как хотелось бы, 2300 Requests per second на Helloworld не особо впечатляет. Вот примеры тестов PHP фреймворков с APC
        doophp.com/benchmark
        • –5
          А Вы где-то видели тесты Phalcon с включенным APC в сравнении с другими фреймворками?
          Я делал тесты на домашнем компьютере. HelloWorld на VanilaPhp выдал около 7000 запросов в секунду, Phalcon в 3 раза меньше, Zend со Smarty и обертками около 260 запросов в секунду.

          А вообще по синтетике не судят. Сейчас Хабр мутузит мой очень слабенький сервер и его LA не превосходит 0.1. По мне, так это лучший показатель, чем ab или siege.
    • 0
      Почему бы ко всему этому не подключить и APC? :) Как я понял, код самого приложения остаётся обычным PHP-кодом, на Си написаны именно классы фреймворка.
  • +4
    Где-то проскакивал пост про реализованный на си зенд фреймворк. Вспомнил о нем, по большей части, из-за того, что этот очень похож на зенд своим оверинжинирингом :)
    • 0
      Да, насколько я знаю, Zend не раз компилили. и да, этот фреймворк очень похож на что-то среднее между Zend 1 и Zend 2.
    • 0
      Я тоже про этот пост вспомнил. Вот он YAF — самый быстрый php фреймворк
      • 0
        Кажется, на тот момент документации было крайне мало и она была на китайском. Сейчас сайт вообще не открывается :)
        • 0
          Дык вот.
          Yaf плох тем, что это Zend Framework 1. А Phalcon среднее между первым и вторым Zend.
          • 0
            Не холивара ради. А чем Вам плох ZF1?
            • 0
              Мне нравится философия использования DI и namespace. Мы пользуемся не самой последней версией Zend 1, так что если это там появилось, то поправьте.
              • 0
                Btw, yaf поддерживает namespaces, и это не zf1, просто API похоже.
  • +2
    Проект безусловно интересный, но пока что опасно его использовать. Если что случится с разработчиками (потеряют интерес, например) даже баг не подпилишь не нырнув с головой в сишный код. Плюс уже упомянутое отсутсвие какой-либо помощи в случае некомпиляции или необходимости скомпилить под Windows.
    • +2
      А я кстати узнал о нем из вашей последней презентации (про современный PHP и будущее Yii), посмотрел что же за зверь так уделывает yii — заинтересовало. А что касается сишного кода, то как мне представляется, там не сложнее разобраться чем в незнакомом php'шном. Скомпиленную библиотеку можно взять с оф.сайта, дополнить можно уже на PHP. Но я понимаю вашу обеспокоенность конкурентом ;-)
      • +1
        Да не, PHALCON вряд-ли конкурент. Всё-таки сильно другой.
        • 0
          Архитектурно да, а вот конечные то цели примерно одинаковы. Они тоже идут в сторону модных трендов (DI, ORM, namespace, tools & etc.). Если написать на Phalcon и Yii одно и тоже приложение окажется по времени сопоставимо, то очевидно что будет выбрано в продакшен. Единственный большой минус Phalcon'a его возраст и размер сообщества, отсюда и возможное недоверие.
          • 0
            Размер сообщества, это одна из причин, по которой я написал этот пост. Я очень надеюсь, что кроме меня этот инструмент, пусть и bag/feature репортами, будут развивать еще люди.
  • +1
    Кстати, тут же стоит упомянуть YAF github.com/laruence/php-yaf
    • +1
      Может и стоит, но по уровню развития, возможностей, документации и поддержки, вряд ли он сравнится с Phalcon.
  • 0
    А сколько у вас ушло времени, чтобы поверхностно разобраться во фреймворке и написать приложение?
    Приходилось ли заглядывать в исходники, или хватило документации?
    • 0
      Какие нафиг исходники? В сишный код чтоли?
      • 0
        А чего вы так удивились? Я заглядываю в исходники того же Yii если мне интересна реализация или непонятен ход работы приложения. Если я знаю (или хотя бы могу прочитать) C, то почему бы не заглянуть
        • 0
          Пока хватило документации. И да, согласен, сам постоянно брожу по исходникам того же Zend.
        • 0
          Одно дело смотреть в исходники на PHP, для этого не нужно знать или хотя бы иметь представление о сях. Средний программист на PHP (в проекте гораздо практичней разбавить опытных разработчико менее опытными) сишный код не переварит.
          • –2
            Честно, если человек сумел разобраться в устройстве и осознанно что-то ищет в том же Zend, ему не составит много труда найти это в C. Посмотрите исходники на гитхаб, многие вещи довольно очевидны.
            • 0
              Проблема в том, что Zend тоже не сильно просто даётся.
    • 0
      Первый раз открыл документацию в середине прошлой недели. Начал писать приложение и разбираться в фреймворке на выходных. Так что дается он быстро.
      разработчики тоже предоставляют тестовое приложение. тыц тыц
  • +1
    Было бы хорошо, тот же тест с включенным АРС + пару простых SELECT запросов на persistent конекте.
    Разница в тестах будет минимальной, в пределах 2-4%.
    Выносить код на С имеет смысл, если у вас производится много логический и мат. операций, в остальном смысл перехода на компиленый фреймворк сводится на нет.
    • –1
      вы серьёзно?
      • 0
        К чему этот вопрос?
  • +1
    По быстродействию его надо с HipHop-PHP сравнить. Интересно что покажут тесты.

    Ранее упомянутый YAF ставится так
    $ pecl install yaf
    $ echo 'extension=yaf.so' > /etc/php5/conf.d/php.ini

    Phalcon ставится так
    $ aptitude install php5-dev php5-mysql gcc
    $ git clone git://github.com/phalcon/cphalcon.git
    $ cd cphalcon/release
    $ phpize
    $ ./configure --enable-phalcon
    $ make && make install
    $ echo 'extension=phalcon.so' > /etc/php5/conf.d/php.ini

    Было бы не плохо если бы Phalcon в PECL стал доступен.
    • 0
      Уже запросили
      Я думал разобраться с Hip-Hop. Можете проконсультировать по одному вопросу? Где-то прочел, что он требует типизированный код. Т.е. есть требования к написанию и используемым функциям. Это так?
    • 0
      Честно говоря не вижу смысла сравнивать с HipHop. Ещё с чисто Сишной программой можно сравнить :)
  • –1
    Cython для PHP. Interesting…
  • 0
    Я собираю Phalcon PHP для Fedora. Там же выложен *.src.rpm -. можно собрать для любого Redhat-соместимого дистрибутива Fedora:

    rpm -ivh http://linux.ria.ua/SRPMS/php-phalcon/php-phalcon-0.6.1.20121111-1.fc17.src.rpm
    cd ~/rpmbuild/SPECS
    rpmbuild -ba php-phalcon-6.1.spec rpm
    


    PS: В некритичных модулях используем на продакшене с php 5.4 + apc уже больше месяца — полет нормальный! :)
    • 0
      Вы разобрались в роутинге? Как назначит роутинг на статичный файл?
      Запрос идет на example.com/tp/bla_params.json и если файла нет, то роутер перенаправляет его на некий контроллер и отдает параметры. У меня никак не хочет работать из-за .json
      • +1
        Отписался в лику с вариантом для такого роута
  • 0
    Попытался отправить форму, а он вывалил трейсбек с паролем к БД

    Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' in /var/www/xmpls_assorium/public/index.php:29
    Stack trace:
    #0 [internal function]: PDO->__construct('mysql:host=loca...', 'xmpl', 'cgfhnfr23', Array)  # <- вот он - пароль!
    #1 [internal function]: Phalcon\Db\Adapter\Pdo->connect(Array)
    #2 /var/www/xmpls_assorium/public/index.php(29): Phalcon\Db\Adapter\Pdo->__construct(Array)
    #3 [internal function]: {closure}()
    #4 [internal function]: Phalcon\DI->_factory(Object(Closure), NULL)
    #5 [internal function]: Phalcon\DI->get('db', NULL)
    #6 [internal function]: Phalcon\DI->getShared('db')
    #7 [internal function]: Phalcon\Mvc\Model->getConnection()
    #8 [internal function]: Phalcon\Mvc\Model::_prepareGroupResult('COUNT', 'rowcount', NULL)
    #9 /var/www/xmpls_assorium/apps/controllers/PollController.php(91): Phalcon\Mvc\Model::count()
    #10 [internal function]: PollController->ajaxAction()
    #11 [internal function]: Phalcon\Dispatcher->dispatch() in /var/www/xmpls_assorium/public/index.php on line 29
    • +2
      Но вообще конечно странное желание — перенести как можно больше кода на C.
      Во первых — разбираться сложнее, во вторых — гораздо легче словить какой-то buffer overflow и прочие дырки.
      • 0
        Это трейсбек выведен умышленно, а не из-за дыр. Но я, к сожалению не думал, что будут выведены такие данные.
        Если есть хорошая документация, то в код фреймворка лезть не нужно. Тут документация достаточно полная.
        Весь код на C наследуется php библиотекой и ограничен настройками ini. Так что словить такие ошибки мало вероятно. Поправте, если не прав.
        • +1
          > Но я, к сожалению не думал, что будут выведены такие данные.

          Эээ. Кхм. Что?

          Ну и это:
          PDO->__construct('mysql:host=loca...', 'xmpl', 'cgfhnfr23', Array)
          доставляет.

          Это ведь юзер и пароль?
          • 0
            А Вы знаете трейсбеки всех функций? Я с PDO работаю впервые.
        • +2
          Насчет «наследуется php библиотекой» не уверен что вы хотели сказать, но в коде фреймворка используется zend API, так что, скорее всего, лимиты по памяти и всякие open base dir оно соблюдает. Но это не помешает ему, в случае если кто-то где-то не доглядел, сделать buffer overflow и тому подобные радости с падением веб-сервера (или воркера fcgi), порчей памяти и даже выполнением кода злоумышленника.

          Тот факт, что используется zend API, соответственно, аллокатор памяти, почти везде типы данных PHP и прочие абстракции, влияет на производительность, кстати! Ибо выполняется вся та же работа, которую выполнил бы интерпретатор PHP, но вручную (скорее всего немного меньше, но всё же).

          Второй минус, на мой взгляд гораздо более важный — развиваться такой фреймворк будет гораздо медленнее PHP-шного аналога, т.к. на C программировать всё-же посложнее будет. Ну и меньше вероятность того, что кто-то будет присылать патчи, т.к. знатоков PHP гораздо больше, чем тех, кто сможет (и захочет) писать вменяемый код на C.

          Третий минус — какая бы ни была документация, но всегда найдется необходимость заглянуть в код.

          Четвертый минус — пошаговым отладчиком по коду фреймворка не пройтись. Профилировщик скорее всего тоже не переварит, не знаю.

          Ну и пятый — в переводе всего кода фреймворка в C просто нет смысла. 80% тормозов создают 20% кода же! Их можно переписывать. Но зачем всё то? Мартышкин труд получается.
          Веб приложения в большинстве случаев масштабируются созданием нескольких фронтендов или навороченным кешированием. Упираются обычно в БД.
      • 0
        Помоему, наоборот, это самое адекватное желание. Сделать функционал и запихать его в C.
      • 0
        Минимизировать оверхид от инструментов — странное желание? Получаем в идеале скорость «плоского» кода и и удобство разработки с фреймворком. Одна из самых частых претензий к фреймворкам именно их скорость, вернее её отсутсвие.
      • +1
        Даже в Python'е достаточно распространенная практика — быстро спрототипировать модуль на python'е, обкатать его, протестировать, и когда все ок — портировать в модуль на С, чтобы быстрее работало. Так что не так уж и странно.
        • 0
          Забыли важный шаг: побенчмаркать и задуматься нужно ли переписывать на C. И если нужно, то какую часть кода нужно переписать, а какую можно оставить в питоне. (Обычно переносят математику и лексеры текста/бинарных данных. Биндинги к сишным библиотекам не считаю «перепиыванием модуля на С»).
          И уж точно в питоне нет ни одного веб-фреймворка на C и, я уверен, никогда не будет. Пишут на C библиотеки, но никак не фреймворки.
  • +1
    • 0
      Половина статьи ни о чем.
      О, давайте сравним HelloWold бенчмарк, о да, а я вот способен написать '<?='Hello Wold!'?>' и это будет работать быстрее вас всех! И вообще время не главное!

      Конечно не главное, пока у тебя нет нагрузки.
      • 0
        Когда она есть, время на обработку кода фреймворка много меньше времени на запросы в базу и собственно получения контента клиентом (если фреймворк не совсем монстр). Ну и PHP очень легко масштабируется путём добавления серверов с фронтом.
  • 0
    Очень уж на Midgard CMF по архитектуре похоже. Приходилось под него разрабатывать. Правда, там была очень странная идея хранить php/html/css/js-код в БД.
  • 0
    Отличный фреймворк, сейчас на нем ради эксперимента строю один из проектов, сам хотел написать про него статью на хабр, но руки не дошли.

    Стоит отметить что при желании в него вкручивается запросто всеми любимый Twig, я же прикрутил Blitz и тоже рад. В целом я доволен фреймворком, ему бы еще поддержку PSR-0 и было бы замечательно. Хотя стоит отметить что и на данном этапе он уже достаточно хорош. Весьма неплохая архитектура, по крайней мере если сравнивать с традиционными фреймворками есть много плюсов в сторону Фалкона. Потому что Zend / Symphony это такие монструзные мега машины, в Yii особенно бесит ClassMap и не говорите мне что можно написать скрипт и все будет замечательно, PSR-0 никто не отменял и так далее…

    По моему скромному мнению это один из лучших легковесных фреймворков.

    К автору я может конечно что то некорректно понял, но по опыту:
    В виндовсе phalcon прекрасно работает, но я не компилировал, просто взял готовую либу на сайте.
    На линуксе с nginx роутинг до JSON файла роутить по моему скромному убеждению надо все таки на уровне nginx. Впрочем смотря что надо было =)
    • 0
      Я тоже планирую поднять на нем один проект.

      Я тоже брал готовую, но она версии 0.6.0, а мне нужна была 0.6.1. Авторы перезалили на сайт, но у меня почему-то все еще отображается 0.6.0 и присутствуют баги с этой версии.

      Насчет роутинга поясню. По сути, клиент всегда получает статику. А внутри работает демон, который по расписанию дергает таску, которая в свою очередь обновляет этот файл, но! Если вдруг демон умер или еще какая будет, то по этому пути должен резолвится скрипт и отдавать тоже самое. Nginx это конечно хорошо, но лазить в его конфиг постоянно и перезагружать сервер уж слишком. В Zend 1 я такое делал спокойно. Буду разбираться, не получится, придется идти в issue на гитхабе.
      • 0
        А можно в целях повышения профессионального навыка спросить? :) Зачем такое?
        • 0
          Ну вот даже в моем случае это бы в разу снизило нагрузку. Сейчас при заходе на страничку xmpl.assorium.ru/poll/results делается 3 ajax запроса. Каждый запрос берет данные из кеша или из БД.

          В любом случае nginx проксирует все через PHP-FPM на PHP. А так бы nginx просто отдал бы статику, которая незаметно для пользователя обновлялась бы сама. Если же статику удалить, то по сути мы бы имели тоже самое, что и сейчас + операция роутинга.
          • 0
            nginx try_files $uri @рhp?
      • 0
        У них там упущение было во внутренней нумерации, версия была 0.6.1, а выдавалась 0.6.0, тут обсуждали и решили проблему github.com/phalcon/cphalcon/issues/191
        • 0
          Дело больше не в цыфрах, а в баге с кешированием вывода.
          Даже получив последние исходники, у меня этот баг остался. Буду все перепроверять.
  • +1
    Почему так мало плюсов за статью? Это же отличный пост. о фремворке никто и не узнает если он еще + 21 не наберет. И не получится большего комьюнити.
    • –1
      Возможно большинство не видит преимуществ. Возможно у многих уже есть фреймворк-любимчик. Или я просто не в то время опубликовал пост.
      • –1
        К сожалению у большинства позиция «нафига это поделие мне мне же надо будет ядро полюбому исправить!» =)
  • 0
    Я впечатлен количеством проделанной работы, именно это ищу уже 2 года. Современное API и чтобы на C. Лишь бы не свернули проект. Им бы не помешало кнопки для дотаций поставить, благодарных думаю будет не мало.
    • 0
      Не факт что много но я уже готов…
      • 0
        Не Вы одни.
  • +3
    Почему-то существует мнение, что скомпилированный код, это решение всех проблем.
    Почему-то считается, что бенчмарки с Hello World и сортировкой пузырьком что-то значат для реальных проектов.

    Кто-то в своих веб-проектах реально упирался в скорость выполнения конструкций языка?
    • +1
      Дело не только в скорости, а в потреблении памяти. Графики для чего здесь выложены? Когда на 1 запрос грузиться сразу 100 классов причем здесь Hello world? Может их сразу стоить держать в памяти, а не грузить каждый раз?
      Возьмите и соедините этих же 100 классов фреймворка которые нужны для запуска Hello Wold в один файл и увидите что сразу как все проседает, т.е. множественное выполнение require менее ресурсоемкое чем один require с 150 классами в одном файле.
      • +1
        1. Что менее ресурсоёмко по вашему так и не понял.

        2. APC?

        3. Реально основную память описание классов занимает? Не структуры данных, не базы? Лев Толстой чтоли тимлид?
        • +1
          Речь идет о конкретных API современным фреймворков которые реализованы в виде «необходимо загрузить 100 классов для обслуживания одного запроса». Так что здесь Толстой не причем. Так как можно конечно написать die('hello world'); и это будет быстрее всего работать. Но не будет ни диспетчера контроллеров, ни диспетчера событий ни ORM, ни шаблонизатора, по сути ничего не будет, то что счас составляет популярное API которое из фреймворка в фреймворк копируется.
          Что значит «реально основную память»? Есть определенный лимит памяти на сервер с системой и всем остальным допустим 1024 Мб. И есть факт потребления памяти и факт торможения приложения из-за множества количества инклудов в современных фреймворках. Если множество инклудов можно решить предзагрузкой классов в виде одного файла со всеми классами, то потребление памяти не решается в том числе с помощью APC.
          Так что если Zend или Symfony нужно 2+ MB чтобы обслужить один простой запрос, то Phalcon нужно 0.5+ MB и причем эту память займет именно как вы заметили «структуры данных», а не байткод из APC.
          • 0
            Если честно, не хочу очередную священную войну на ровном месте разводить.
            Вполне возможно, конкретно вы понимаете все плюсы и минусы обоих подходов и выбираете своё решение обоснованно.
            Просто для очень многих «скомпилированный» это такое волшебное слово, типа, всё настолько здорово и хорошо, а вот что именно хорошо, ответить не могут.
          • 0
            Zend и Symfony очень объемные фреймворки, на сколько объективно их сравнивать с Phalcon по потреблению памяти? Возможно Phalcon не реализует столько логики и интерфейсов. Можно сравнить с каким-нибудь FatFree и выйгрыша в оперативной памяти не будет. Первым делом я подумал, что по логике скомпилированный код должен выполняться быстрее, но с другой стороны если он использует стандартные механизмы PHP откуда бы этому взяться?

            • –2
              Что например нет в Phalcon что есть в Zend/Symfony, если можно конкретно в выполнении обычного запроса? Если вы читали примеры, то Phalcon очень похож на Zend 1 в реализации логики обработки запроса, но почему то Zend стоит в конце по производительности. Например тот же CodeIgniter очень тонкий фреймворк, но на графиках в статье можете увидеть значительный проигрыш по всем параметрам.
              // но с другой стороны если он использует стандартные механизмы PHP откуда бы этому взяться?
              Это есть в документации на php.net. Вызов пользовательских функций медленнее, нежели функций из ядра или расширения. Как пример шаблонизатор Twig идет с маленьким сишным расширением для получения атрибутов, который реализует вызов всего одного метода Twig_Template::getAttribute(). Думаете если бы это не нужно было, его бы писали?
              • 0
                По поводу вызова пользовательских функций бесспорно. Если это дает большой прирост, замечательно. Вопрос в том используется ли Phalcon для ускорения специфических задач расчета и поиска или же в нем достаточно много вызовов стандартных механизмов PHP например работа с массивами?
                • 0
                  Не совсем понимаю вопрос. У Phalcon есть свое ядро в том числе для работы с массивами если вы об этом. Но естественно расширение использует API самого интерпретатора иначе это уже не расширение будет.
                  • 0
                    Да об этом. Тяжелые операции берет на свой код, отлично.
  • 0
    а нет ли где русскоязычного сообщества по этому фреймворку?
    • 0
      с 99% вероятностью скажу что нет, ибо он еще совсем зеленый и необкатанный
      • 0
        Все с чего-то начинают. На меня фэлкон произвёл очень приятное впечатление, а любой добротный продукт становится популярным. Так что русскому сообществу быть.
      • 0
        Довольно голословно. В гугл группах, уже ведутся обсуждения проектов на phalcon. В 0.7.0 они вывели наружу 14 интерфейсов, так что зависимость от сторонних разработчиков практически полностью пропала. Все что угодно можно расширить.
        Также они создали инкубатор, где каждый может предложить PHP код для фреймворка, который они переведут в C.
    • 0
      Тут посмотрите: gitter.im/phalcon-rus/chat
      В общем-то фреймворк уже «оброс» русской частью сообщества, насколько я вижу. Я понимаю что это не показатель, но даже в вк уже группа есть.

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