Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 101
Довольно приятный фреймворк. Но на шаред хостингах его не заюзаешь.
Когда писал недостатки, этот вариант крутился в голове. Спасибо, что напомнили.
Да, к сожалению это проблема.
Да, к сожалению это проблема.
а чего забыли про pecl.php.net/package/yaf?
>И на шаред хостинги его не поставишь.
Думаю это не разу не проблема.
Учитывая что на Шаред/Виртуал хостинги устанавливаются сайты, которые не должны блистать скоростями на высоких нагрузках.
А если пишется крупный проект, с бешеным онлайном и клиент платит бешеные деньги за повышенную скорость работы сайта, именно программистам? Я бы взял такой инструмент, сразу мы экономим время (а значит и деньги) на скорости разработки и выполняем условие заказчика.
Думаю это не разу не проблема.
Учитывая что на Шаред/Виртуал хостинги устанавливаются сайты, которые не должны блистать скоростями на высоких нагрузках.
А если пишется крупный проект, с бешеным онлайном и клиент платит бешеные деньги за повышенную скорость работы сайта, именно программистам? Я бы взял такой инструмент, сразу мы экономим время (а значит и деньги) на скорости разработки и выполняем условие заказчика.
Этот инструмент экономит время еще и благодаря этому.
Я мельком упомянул инструменты разработчика. Они позволяют создать каркас и полную внутреннюю структуру для пустого приложения.
Я мельком упомянул инструменты разработчика. Они позволяют создать каркас и полную внутреннюю структуру для пустого приложения.
«Phalcon — самый быстрый PHP MVC Framework».
Мне кажется, что обращать внимание в заголовке на один из качеств фрймверка не корректно.
Зачем мы используем фреймверки? Для того чтобы облегчить рутинные операции (для того чтобы посадить еще менее грамотного программиста), мы задумываемся прежде всего об удобстве и простоте использования инструмента и уже потом о скорости, оптимизациях.
Быстрый не значит удобный и простой.
Например, почему популярен язык Java, хотя по скорости далеко не самый быстрый инструмент?
Мне кажется, что обращать внимание в заголовке на один из качеств фрймверка не корректно.
Зачем мы используем фреймверки? Для того чтобы облегчить рутинные операции (для того чтобы посадить еще менее грамотного программиста), мы задумываемся прежде всего об удобстве и простоте использования инструмента и уже потом о скорости, оптимизациях.
Быстрый не значит удобный и простой.
Например, почему популярен язык Java, хотя по скорости далеко не самый быстрый инструмент?
Признаю, заголовок желтый. Но именно такой заголовок и привлек мое внимание в зарубежных блогах.
Все зависит от задач и возможностей. Имея 256 RAM, удобные фреймворки могут съесть всю память на паре клиентов.
А если фреймворк и удобный и быстрый, то это золотая жила. Я бы оценил phalcon в виду его молодости ( 0.6.1 ) на 4.5/5
Все зависит от задач и возможностей. Имея 256 RAM, удобные фреймворки могут съесть всю память на паре клиентов.
А если фреймворк и удобный и быстрый, то это золотая жила. Я бы оценил phalcon в виду его молодости ( 0.6.1 ) на 4.5/5
Имея 256 RAM, удобные фреймворки могут съесть всю память на паре клиентов.
Врете вы всё. Вы реально упирались в производительность php в ваших веб-приложениях?
С чего взяли, что вру? У меня работающий клиент, который выдерживал более 70000 одновременных запросов на Zend. Выдержал, только благодаря мощной тачке и разумной настройке.
Этот же клиент уложил на лопатки мой локальный компьютер, при подключении к нему около 10 пользователей (там частота вызовов гораздо больше, но все же).
Попробуйте представить сколько памяти ест Zend. Попробуйте представить сколько памяти ест Zend с включенным APC.
Прямо сейчас меня ддосят. Ничего не предпринимаю. Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД. LA доходит до 6. Память почти на нуле. Но сайт ни разу не упал. Более чем уверен, тот же сайт но на Zend уже давно бы валялся.
Этот же клиент уложил на лопатки мой локальный компьютер, при подключении к нему около 10 пользователей (там частота вызовов гораздо больше, но все же).
Попробуйте представить сколько памяти ест Zend. Попробуйте представить сколько памяти ест Zend с включенным APC.
Прямо сейчас меня ддосят. Ничего не предпринимаю. Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД. LA доходит до 6. Память почти на нуле. Но сайт ни разу не упал. Более чем уверен, тот же сайт но на Zend уже давно бы валялся.
У меня работающий клиент, который выдерживал более 70000 одновременных запросов на Zend
70 тысяч запросов на Zend это что значит? 70k req/sec? 70k req/day?
Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.
60 запросов в секунду это не DDOS :)
к скрипту с 12 запросами к БД.
Сколько миллионов записей на таблицу, какой характер запросов — write/read? Какая репликация / может у вас шардинг?
Более чем уверен, тот же сайт но на Zend уже давно бы валялся.
Вы зря так уверены :) Вопрос ведь не в интерпритаторе php. Ну включили APC, не гоняет теперь байткод каждый раз. А вот к БД нужно открыть коннект, закрыть коннект, прочитать что-то, записать что-то.
Я не к тому, что фреймворк — «плохо, плохо, руки прочь», я к тому, что вы как-то уж больно много нагрузки вкладываете в роутинг и десяток классов фреймворка. Что ZF, что yii.
60 rps из которых 12 rps к базе вы называете DDOS'ом?
Ок.
А то у меня 187 rps к базе, и я всегда считал, что это — штатная ситуация. Буду знать, что меня дидосят, да. Все, кидаюсь менять Invision Powerboard (говоно еще то) на Phalcon!
Ок.
А то у меня 187 rps к базе, и я всегда считал, что это — штатная ситуация. Буду знать, что меня дидосят, да. Все, кидаюсь менять Invision Powerboard (говоно еще то) на Phalcon!
60 rps только с одного ip, во-первых
каждый из запросов создает от 1 до 12 запросов к бд, во-вторых
у меня очень маленький и слабый сервер, в-третьих
Мне кажется, что Вы путаете понятия CMS и Framework
каждый из запросов создает от 1 до 12 запросов к бд, во-вторых
у меня очень маленький и слабый сервер, в-третьих
Invision Powerboard
Мне кажется, что Вы путаете понятия CMS и Framework
> 60 rps только с одного ip, во-первых
Других цифр озвучено не было:
Прямо сейчас меня ддосят. Ничего не предпринимаю. Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.
> у меня очень маленький и слабый сервер
Это нам тоже неизвестно.
> Мне кажется, что Вы путаете понятия CMS и Framework
Я не путаю. Это была ирония
Других цифр озвучено не было:
Прямо сейчас меня ддосят. Ничего не предпринимаю. Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.
> у меня очень маленький и слабый сервер
Это нам тоже неизвестно.
> Мне кажется, что Вы путаете понятия CMS и Framework
Я не путаю. Это была ирония
60 запросов с одного адреса называется распределённой атакой. Нормально. :3
Почему бы не поставить APC вместо всего этого?
А как вы собрались использовать APC вместо фреймворка? Расскажите.
Phalcon будет в несколько раз быстрее любого фреймворка даже с APC.
Вы же не будете утверждать, что код на C и код на PHP c APC работает одинаково быстро?
А когда дело касается монстров типа симфони2 и зенд2, то это как небо и земля.
Вы же не будете утверждать, что код на C и код на PHP c APC работает одинаково быстро?
А когда дело касается монстров типа симфони2 и зенд2, то это как небо и земля.
Если судить по тестам то Phalcon не нас только быстр как хотелось бы, 2300 Requests per second на Helloworld не особо впечатляет. Вот примеры тестов PHP фреймворков с APC
doophp.com/benchmark
doophp.com/benchmark
А Вы где-то видели тесты Phalcon с включенным APC в сравнении с другими фреймворками?
Я делал тесты на домашнем компьютере. HelloWorld на VanilaPhp выдал около 7000 запросов в секунду, Phalcon в 3 раза меньше, Zend со Smarty и обертками около 260 запросов в секунду.
А вообще по синтетике не судят. Сейчас Хабр мутузит мой очень слабенький сервер и его LA не превосходит 0.1. По мне, так это лучший показатель, чем ab или siege.
Я делал тесты на домашнем компьютере. HelloWorld на VanilaPhp выдал около 7000 запросов в секунду, Phalcon в 3 раза меньше, Zend со Smarty и обертками около 260 запросов в секунду.
А вообще по синтетике не судят. Сейчас Хабр мутузит мой очень слабенький сервер и его LA не превосходит 0.1. По мне, так это лучший показатель, чем ab или siege.
Почему бы ко всему этому не подключить и APC? :) Как я понял, код самого приложения остаётся обычным PHP-кодом, на Си написаны именно классы фреймворка.
Где-то проскакивал пост про реализованный на си зенд фреймворк. Вспомнил о нем, по большей части, из-за того, что этот очень похож на зенд своим оверинжинирингом :)
Да, насколько я знаю, Zend не раз компилили. и да, этот фреймворк очень похож на что-то среднее между Zend 1 и Zend 2.
Я тоже про этот пост вспомнил. Вот он YAF — самый быстрый php фреймворк
Кажется, на тот момент документации было крайне мало и она была на китайском. Сейчас сайт вообще не открывается :)
Дык вот.
Yaf плох тем, что это Zend Framework 1. А Phalcon среднее между первым и вторым Zend.
Yaf плох тем, что это Zend Framework 1. А Phalcon среднее между первым и вторым Zend.
Проект безусловно интересный, но пока что опасно его использовать. Если что случится с разработчиками (потеряют интерес, например) даже баг не подпилишь не нырнув с головой в сишный код. Плюс уже упомянутое отсутсвие какой-либо помощи в случае некомпиляции или необходимости скомпилить под Windows.
А я кстати узнал о нем из вашей последней презентации (про современный PHP и будущее Yii), посмотрел что же за зверь так уделывает yii — заинтересовало. А что касается сишного кода, то как мне представляется, там не сложнее разобраться чем в незнакомом php'шном. Скомпиленную библиотеку можно взять с оф.сайта, дополнить можно уже на PHP. Но я понимаю вашу обеспокоенность конкурентом ;-)
Да не, PHALCON вряд-ли конкурент. Всё-таки сильно другой.
Архитектурно да, а вот конечные то цели примерно одинаковы. Они тоже идут в сторону модных трендов (DI, ORM, namespace, tools & etc.). Если написать на Phalcon и Yii одно и тоже приложение окажется по времени сопоставимо, то очевидно что будет выбрано в продакшен. Единственный большой минус Phalcon'a его возраст и размер сообщества, отсюда и возможное недоверие.
Кстати, тут же стоит упомянуть YAF github.com/laruence/php-yaf
А сколько у вас ушло времени, чтобы поверхностно разобраться во фреймворке и написать приложение?
Приходилось ли заглядывать в исходники, или хватило документации?
Приходилось ли заглядывать в исходники, или хватило документации?
Какие нафиг исходники? В сишный код чтоли?
А чего вы так удивились? Я заглядываю в исходники того же Yii если мне интересна реализация или непонятен ход работы приложения. Если я знаю (или хотя бы могу прочитать) C, то почему бы не заглянуть
Пока хватило документации. И да, согласен, сам постоянно брожу по исходникам того же Zend.
Одно дело смотреть в исходники на PHP, для этого не нужно знать или хотя бы иметь представление о сях. Средний программист на PHP (в проекте гораздо практичней разбавить опытных разработчико менее опытными) сишный код не переварит.
Было бы хорошо, тот же тест с включенным АРС + пару простых SELECT запросов на persistent конекте.
Разница в тестах будет минимальной, в пределах 2-4%.
Выносить код на С имеет смысл, если у вас производится много логический и мат. операций, в остальном смысл перехода на компиленый фреймворк сводится на нет.
Разница в тестах будет минимальной, в пределах 2-4%.
Выносить код на С имеет смысл, если у вас производится много логический и мат. операций, в остальном смысл перехода на компиленый фреймворк сводится на нет.
По быстродействию его надо с HipHop-PHP сравнить. Интересно что покажут тесты.
Ранее упомянутый YAF ставится так
Phalcon ставится так
Было бы не плохо если бы Phalcon в PECL стал доступен.
Ранее упомянутый 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 стал доступен.
Уже запросили
Я думал разобраться с Hip-Hop. Можете проконсультировать по одному вопросу? Где-то прочел, что он требует типизированный код. Т.е. есть требования к написанию и используемым функциям. Это так?
Я думал разобраться с Hip-Hop. Можете проконсультировать по одному вопросу? Где-то прочел, что он требует типизированный код. Т.е. есть требования к написанию и используемым функциям. Это так?
Сам не использовал HipHop-php, но вот тут есть описание подводных камней habrahabr.ru/post/138521/ и тут github.com/facebook/hiphop-php/blob/master/doc/inconsistencies
Честно говоря не вижу смысла сравнивать с HipHop. Ещё с чисто Сишной программой можно сравнить :)
Cython для PHP. Interesting…
Я собираю Phalcon PHP для Fedora. Там же выложен *.src.rpm -. можно собрать для любого Redhat-соместимого дистрибутива Fedora:
PS: В некритичных модулях используем на продакшене с php 5.4 + apc уже больше месяца — полет нормальный! :)
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 уже больше месяца — полет нормальный! :)
Вы разобрались в роутинге? Как назначит роутинг на статичный файл?
Запрос идет на example.com/tp/bla_params.json и если файла нет, то роутер перенаправляет его на некий контроллер и отдает параметры. У меня никак не хочет работать из-за .json
Запрос идет на example.com/tp/bla_params.json и если файла нет, то роутер перенаправляет его на некий контроллер и отдает параметры. У меня никак не хочет работать из-за .json
Попытался отправить форму, а он вывалил трейсбек с паролем к БД
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Но вообще конечно странное желание — перенести как можно больше кода на C.
Во первых — разбираться сложнее, во вторых — гораздо легче словить какой-то buffer overflow и прочие дырки.
Во первых — разбираться сложнее, во вторых — гораздо легче словить какой-то buffer overflow и прочие дырки.
Это трейсбек выведен умышленно, а не из-за дыр. Но я, к сожалению не думал, что будут выведены такие данные.
Если есть хорошая документация, то в код фреймворка лезть не нужно. Тут документация достаточно полная.
Весь код на C наследуется php библиотекой и ограничен настройками ini. Так что словить такие ошибки мало вероятно. Поправте, если не прав.
Если есть хорошая документация, то в код фреймворка лезть не нужно. Тут документация достаточно полная.
Весь код на C наследуется php библиотекой и ограничен настройками ini. Так что словить такие ошибки мало вероятно. Поправте, если не прав.
> Но я, к сожалению не думал, что будут выведены такие данные.
Эээ. Кхм. Что?
Ну и это:
PDO->__construct('mysql:host=loca...', 'xmpl', 'cgfhnfr23', Array)
доставляет.
Это ведь юзер и пароль?
Эээ. Кхм. Что?
Ну и это:
PDO->__construct('mysql:host=loca...', 'xmpl', 'cgfhnfr23', Array)
доставляет.
Это ведь юзер и пароль?
А Вы знаете трейсбеки всех функций? Я с PDO работаю впервые.
Я высказал предположение. Которое верно: php.net/manual/en/pdo.construct.php
Насчет «наследуется php библиотекой» не уверен что вы хотели сказать, но в коде фреймворка используется zend API, так что, скорее всего, лимиты по памяти и всякие open base dir оно соблюдает. Но это не помешает ему, в случае если кто-то где-то не доглядел, сделать buffer overflow и тому подобные радости с падением веб-сервера (или воркера fcgi), порчей памяти и даже выполнением кода злоумышленника.
Тот факт, что используется zend API, соответственно, аллокатор памяти, почти везде типы данных PHP и прочие абстракции, влияет на производительность, кстати! Ибо выполняется вся та же работа, которую выполнил бы интерпретатор PHP, но вручную (скорее всего немного меньше, но всё же).
Второй минус, на мой взгляд гораздо более важный — развиваться такой фреймворк будет гораздо медленнее PHP-шного аналога, т.к. на C программировать всё-же посложнее будет. Ну и меньше вероятность того, что кто-то будет присылать патчи, т.к. знатоков PHP гораздо больше, чем тех, кто сможет (и захочет) писать вменяемый код на C.
Третий минус — какая бы ни была документация, но всегда найдется необходимость заглянуть в код.
Четвертый минус — пошаговым отладчиком по коду фреймворка не пройтись. Профилировщик скорее всего тоже не переварит, не знаю.
Ну и пятый — в переводе всего кода фреймворка в C просто нет смысла. 80% тормозов создают 20% кода же! Их можно переписывать. Но зачем всё то? Мартышкин труд получается.
Веб приложения в большинстве случаев масштабируются созданием нескольких фронтендов или навороченным кешированием. Упираются обычно в БД.
Тот факт, что используется zend API, соответственно, аллокатор памяти, почти везде типы данных PHP и прочие абстракции, влияет на производительность, кстати! Ибо выполняется вся та же работа, которую выполнил бы интерпретатор PHP, но вручную (скорее всего немного меньше, но всё же).
Второй минус, на мой взгляд гораздо более важный — развиваться такой фреймворк будет гораздо медленнее PHP-шного аналога, т.к. на C программировать всё-же посложнее будет. Ну и меньше вероятность того, что кто-то будет присылать патчи, т.к. знатоков PHP гораздо больше, чем тех, кто сможет (и захочет) писать вменяемый код на C.
Третий минус — какая бы ни была документация, но всегда найдется необходимость заглянуть в код.
Четвертый минус — пошаговым отладчиком по коду фреймворка не пройтись. Профилировщик скорее всего тоже не переварит, не знаю.
Ну и пятый — в переводе всего кода фреймворка в C просто нет смысла. 80% тормозов создают 20% кода же! Их можно переписывать. Но зачем всё то? Мартышкин труд получается.
Веб приложения в большинстве случаев масштабируются созданием нескольких фронтендов или навороченным кешированием. Упираются обычно в БД.
Помоему, наоборот, это самое адекватное желание. Сделать функционал и запихать его в C.
Минимизировать оверхид от инструментов — странное желание? Получаем в идеале скорость «плоского» кода и и удобство разработки с фреймворком. Одна из самых частых претензий к фреймворкам именно их скорость, вернее её отсутсвие.
Даже в Python'е достаточно распространенная практика — быстро спрототипировать модуль на python'е, обкатать его, протестировать, и когда все ок — портировать в модуль на С, чтобы быстрее работало. Так что не так уж и странно.
Забыли важный шаг: побенчмаркать и задуматься нужно ли переписывать на C. И если нужно, то какую часть кода нужно переписать, а какую можно оставить в питоне. (Обычно переносят математику и лексеры текста/бинарных данных. Биндинги к сишным библиотекам не считаю «перепиыванием модуля на С»).
И уж точно в питоне нет ни одного веб-фреймворка на C и, я уверен, никогда не будет. Пишут на C библиотеки, но никак не фреймворки.
И уж точно в питоне нет ни одного веб-фреймворка на C и, я уверен, никогда не будет. Пишут на C библиотеки, но никак не фреймворки.
Есть мнение, что не все так радужно с PECL-фреймворками.
Очень уж на Midgard CMF по архитектуре похоже. Приходилось под него разрабатывать. Правда, там была очень странная идея хранить php/html/css/js-код в БД.
Отличный фреймворк, сейчас на нем ради эксперимента строю один из проектов, сам хотел написать про него статью на хабр, но руки не дошли.
Стоит отметить что при желании в него вкручивается запросто всеми любимый Twig, я же прикрутил Blitz и тоже рад. В целом я доволен фреймворком, ему бы еще поддержку PSR-0 и было бы замечательно. Хотя стоит отметить что и на данном этапе он уже достаточно хорош. Весьма неплохая архитектура, по крайней мере если сравнивать с традиционными фреймворками есть много плюсов в сторону Фалкона. Потому что Zend / Symphony это такие монструзные мега машины, в Yii особенно бесит ClassMap и не говорите мне что можно написать скрипт и все будет замечательно, PSR-0 никто не отменял и так далее…
По моему скромному мнению это один из лучших легковесных фреймворков.
К автору я может конечно что то некорректно понял, но по опыту:
В виндовсе phalcon прекрасно работает, но я не компилировал, просто взял готовую либу на сайте.
На линуксе с nginx роутинг до JSON файла роутить по моему скромному убеждению надо все таки на уровне nginx. Впрочем смотря что надо было =)
Стоит отметить что при желании в него вкручивается запросто всеми любимый Twig, я же прикрутил Blitz и тоже рад. В целом я доволен фреймворком, ему бы еще поддержку PSR-0 и было бы замечательно. Хотя стоит отметить что и на данном этапе он уже достаточно хорош. Весьма неплохая архитектура, по крайней мере если сравнивать с традиционными фреймворками есть много плюсов в сторону Фалкона. Потому что Zend / Symphony это такие монструзные мега машины, в Yii особенно бесит ClassMap и не говорите мне что можно написать скрипт и все будет замечательно, PSR-0 никто не отменял и так далее…
По моему скромному мнению это один из лучших легковесных фреймворков.
К автору я может конечно что то некорректно понял, но по опыту:
В виндовсе phalcon прекрасно работает, но я не компилировал, просто взял готовую либу на сайте.
На линуксе с nginx роутинг до JSON файла роутить по моему скромному убеждению надо все таки на уровне nginx. Впрочем смотря что надо было =)
Я тоже планирую поднять на нем один проект.
Я тоже брал готовую, но она версии 0.6.0, а мне нужна была 0.6.1. Авторы перезалили на сайт, но у меня почему-то все еще отображается 0.6.0 и присутствуют баги с этой версии.
Насчет роутинга поясню. По сути, клиент всегда получает статику. А внутри работает демон, который по расписанию дергает таску, которая в свою очередь обновляет этот файл, но! Если вдруг демон умер или еще какая будет, то по этому пути должен резолвится скрипт и отдавать тоже самое. Nginx это конечно хорошо, но лазить в его конфиг постоянно и перезагружать сервер уж слишком. В Zend 1 я такое делал спокойно. Буду разбираться, не получится, придется идти в issue на гитхабе.
Я тоже брал готовую, но она версии 0.6.0, а мне нужна была 0.6.1. Авторы перезалили на сайт, но у меня почему-то все еще отображается 0.6.0 и присутствуют баги с этой версии.
Насчет роутинга поясню. По сути, клиент всегда получает статику. А внутри работает демон, который по расписанию дергает таску, которая в свою очередь обновляет этот файл, но! Если вдруг демон умер или еще какая будет, то по этому пути должен резолвится скрипт и отдавать тоже самое. Nginx это конечно хорошо, но лазить в его конфиг постоянно и перезагружать сервер уж слишком. В Zend 1 я такое делал спокойно. Буду разбираться, не получится, придется идти в issue на гитхабе.
А можно в целях повышения профессионального навыка спросить? :) Зачем такое?
Ну вот даже в моем случае это бы в разу снизило нагрузку. Сейчас при заходе на страничку xmpl.assorium.ru/poll/results делается 3 ajax запроса. Каждый запрос берет данные из кеша или из БД.
В любом случае nginx проксирует все через PHP-FPM на PHP. А так бы nginx просто отдал бы статику, которая незаметно для пользователя обновлялась бы сама. Если же статику удалить, то по сути мы бы имели тоже самое, что и сейчас + операция роутинга.
В любом случае nginx проксирует все через PHP-FPM на PHP. А так бы nginx просто отдал бы статику, которая незаметно для пользователя обновлялась бы сама. Если же статику удалить, то по сути мы бы имели тоже самое, что и сейчас + операция роутинга.
У них там упущение было во внутренней нумерации, версия была 0.6.1, а выдавалась 0.6.0, тут обсуждали и решили проблему github.com/phalcon/cphalcon/issues/191
Дело больше не в цыфрах, а в баге с кешированием вывода.
Даже получив последние исходники, у меня этот баг остался. Буду все перепроверять.
Даже получив последние исходники, у меня этот баг остался. Буду все перепроверять.
Почему так мало плюсов за статью? Это же отличный пост. о фремворке никто и не узнает если он еще + 21 не наберет. И не получится большего комьюнити.
Я впечатлен количеством проделанной работы, именно это ищу уже 2 года. Современное API и чтобы на C. Лишь бы не свернули проект. Им бы не помешало кнопки для дотаций поставить, благодарных думаю будет не мало.
Почему-то существует мнение, что скомпилированный код, это решение всех проблем.
Почему-то считается, что бенчмарки с Hello World и сортировкой пузырьком что-то значат для реальных проектов.
Кто-то в своих веб-проектах реально упирался в скорость выполнения конструкций языка?
Почему-то считается, что бенчмарки с Hello World и сортировкой пузырьком что-то значат для реальных проектов.
Кто-то в своих веб-проектах реально упирался в скорость выполнения конструкций языка?
Дело не только в скорости, а в потреблении памяти. Графики для чего здесь выложены? Когда на 1 запрос грузиться сразу 100 классов причем здесь Hello world? Может их сразу стоить держать в памяти, а не грузить каждый раз?
Возьмите и соедините этих же 100 классов фреймворка которые нужны для запуска Hello Wold в один файл и увидите что сразу как все проседает, т.е. множественное выполнение require менее ресурсоемкое чем один require с 150 классами в одном файле.
Возьмите и соедините этих же 100 классов фреймворка которые нужны для запуска Hello Wold в один файл и увидите что сразу как все проседает, т.е. множественное выполнение require менее ресурсоемкое чем один require с 150 классами в одном файле.
1. Что менее ресурсоёмко по вашему так и не понял.
2. APC?
3. Реально основную память описание классов занимает? Не структуры данных, не базы? Лев Толстой чтоли тимлид?
2. APC?
3. Реально основную память описание классов занимает? Не структуры данных, не базы? Лев Толстой чтоли тимлид?
Речь идет о конкретных API современным фреймворков которые реализованы в виде «необходимо загрузить 100 классов для обслуживания одного запроса». Так что здесь Толстой не причем. Так как можно конечно написать die('hello world'); и это будет быстрее всего работать. Но не будет ни диспетчера контроллеров, ни диспетчера событий ни ORM, ни шаблонизатора, по сути ничего не будет, то что счас составляет популярное API которое из фреймворка в фреймворк копируется.
Что значит «реально основную память»? Есть определенный лимит памяти на сервер с системой и всем остальным допустим 1024 Мб. И есть факт потребления памяти и факт торможения приложения из-за множества количества инклудов в современных фреймворках. Если множество инклудов можно решить предзагрузкой классов в виде одного файла со всеми классами, то потребление памяти не решается в том числе с помощью APC.
Так что если Zend или Symfony нужно 2+ MB чтобы обслужить один простой запрос, то Phalcon нужно 0.5+ MB и причем эту память займет именно как вы заметили «структуры данных», а не байткод из APC.
Что значит «реально основную память»? Есть определенный лимит памяти на сервер с системой и всем остальным допустим 1024 Мб. И есть факт потребления памяти и факт торможения приложения из-за множества количества инклудов в современных фреймворках. Если множество инклудов можно решить предзагрузкой классов в виде одного файла со всеми классами, то потребление памяти не решается в том числе с помощью APC.
Так что если Zend или Symfony нужно 2+ MB чтобы обслужить один простой запрос, то Phalcon нужно 0.5+ MB и причем эту память займет именно как вы заметили «структуры данных», а не байткод из APC.
Если честно, не хочу очередную священную войну на ровном месте разводить.
Вполне возможно, конкретно вы понимаете все плюсы и минусы обоих подходов и выбираете своё решение обоснованно.
Просто для очень многих «скомпилированный» это такое волшебное слово, типа, всё настолько здорово и хорошо, а вот что именно хорошо, ответить не могут.
Вполне возможно, конкретно вы понимаете все плюсы и минусы обоих подходов и выбираете своё решение обоснованно.
Просто для очень многих «скомпилированный» это такое волшебное слово, типа, всё настолько здорово и хорошо, а вот что именно хорошо, ответить не могут.
Zend и Symfony очень объемные фреймворки, на сколько объективно их сравнивать с Phalcon по потреблению памяти? Возможно Phalcon не реализует столько логики и интерфейсов. Можно сравнить с каким-нибудь FatFree и выйгрыша в оперативной памяти не будет. Первым делом я подумал, что по логике скомпилированный код должен выполняться быстрее, но с другой стороны если он использует стандартные механизмы PHP откуда бы этому взяться?
Что например нет в Phalcon что есть в Zend/Symfony, если можно конкретно в выполнении обычного запроса? Если вы читали примеры, то Phalcon очень похож на Zend 1 в реализации логики обработки запроса, но почему то Zend стоит в конце по производительности. Например тот же CodeIgniter очень тонкий фреймворк, но на графиках в статье можете увидеть значительный проигрыш по всем параметрам.
// но с другой стороны если он использует стандартные механизмы PHP откуда бы этому взяться?
Это есть в документации на php.net. Вызов пользовательских функций медленнее, нежели функций из ядра или расширения. Как пример шаблонизатор Twig идет с маленьким сишным расширением для получения атрибутов, который реализует вызов всего одного метода Twig_Template::getAttribute(). Думаете если бы это не нужно было, его бы писали?
// но с другой стороны если он использует стандартные механизмы PHP откуда бы этому взяться?
Это есть в документации на php.net. Вызов пользовательских функций медленнее, нежели функций из ядра или расширения. Как пример шаблонизатор Twig идет с маленьким сишным расширением для получения атрибутов, который реализует вызов всего одного метода Twig_Template::getAttribute(). Думаете если бы это не нужно было, его бы писали?
а нет ли где русскоязычного сообщества по этому фреймворку?
с 99% вероятностью скажу что нет, ибо он еще совсем зеленый и необкатанный
Все с чего-то начинают. На меня фэлкон произвёл очень приятное впечатление, а любой добротный продукт становится популярным. Так что русскому сообществу быть.
Довольно голословно. В гугл группах, уже ведутся обсуждения проектов на phalcon. В 0.7.0 они вывели наружу 14 интерфейсов, так что зависимость от сторонних разработчиков практически полностью пропала. Все что угодно можно расширить.
Также они создали инкубатор, где каждый может предложить PHP код для фреймворка, который они переведут в C.
Также они создали инкубатор, где каждый может предложить PHP код для фреймворка, который они переведут в C.
Тут посмотрите: gitter.im/phalcon-rus/chat
В общем-то фреймворк уже «оброс» русской частью сообщества, насколько я вижу. Я понимаю что это не показатель, но даже в вк уже группа есть.
В общем-то фреймворк уже «оброс» русской частью сообщества, насколько я вижу. Я понимаю что это не показатель, но даже в вк уже группа есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Phalcon — скомпилированный PHP MVC Framework