Comments 33
> Также удивило отсутствие возможности мерджить конфиги.
docs.phalconphp.com/ru/latest/api/Phalcon_Config.html
public merge (Phalcon\Config $config)
docs.phalconphp.com/ru/latest/api/Phalcon_Config.html
public merge (Phalcon\Config $config)
$di->setShared('cache', $cacheObject);
или
$di->set('cache', $cacheObject, true);
или
$di->set('cache', $cacheObject, true);
От php отказаться не получится
Есть такая замечательная вещь как PHP-CPP, которая может помочь вынести нагруженные места в С++ без сильной головной боли из-за сложного Zend Engine.
Почему не попробывали hhvm? B php работает и с++ апи вполне хорош
подтверждаю, на чистом yii он раза в 1.5-2 медленнее обычного fpm и раза в 2.5 в простом варианте синтетического теста, в котором я в цикле увеличиваю счетчик и веременную добавляю чмсло в степени счетчика и так до 100000. запускал по 100 раз через hhvm и через php cli и там разница была просто огромная в пользу cli. но это на конфигах из коробки.
Тоже видел бенчмарки, которые совсем не радовали. И все же не думаю, что в FB зря потратили время. Возможно не правильно готовят
Полностью согласен. Что-то упущено в инфе от ФБ, но я сразу оговорился, что использовал базовые конфиги, возможно хитрое шаманство позволит разогнать hhvm…
Возможно всему виной то, что Yii во всю использует магические методы (_get/__call). HHVM инлайнит геттеры, так что вызов геттера или обращение напрямую к свойству будут одинаково быстры. Магические методы же медленнее чем просто вызовы методов, ну и плохо поддаются оптимизациям. Хотя это не должно было повлиять настолько сильно. Ну и крайне интересно как вы получили грустные результаты на математических операциях. Возможно просто слишком маленькое количество итераций, или не учитывалось время старта HHVM и т.д. Словом — слишком расплывчато. Я пока не видел ни одного бенчмарка с сильно грустными результатами.
Хотя в итоге все равно нужно видеть код. Вообще было бы неплохо написать простое приложение (желательно RESTFull-сервис) на нескольких фреймворках (например покрыть весь функционал Behat-тестами дабы нивелировать различия) и уже имея на руках несколько различных реализаций (причем желательно включить и Phalcon туда-же) уже делать какие-то выводы… Ну и эксперементировать с различными подходами. Да и будет наглядное сравнение о том как тот или иной функционал реализуется в контексте разных фреймворков. Так же было бы неплохо резюмировать статистику о времени затраченном на разработку функционала (приблизительно).
Хотя в итоге все равно нужно видеть код. Вообще было бы неплохо написать простое приложение (желательно RESTFull-сервис) на нескольких фреймворках (например покрыть весь функционал Behat-тестами дабы нивелировать различия) и уже имея на руках несколько различных реализаций (причем желательно включить и Phalcon туда-же) уже делать какие-то выводы… Ну и эксперементировать с различными подходами. Да и будет наглядное сравнение о том как тот или иной функционал реализуется в контексте разных фреймворков. Так же было бы неплохо резюмировать статистику о времени затраченном на разработку функционала (приблизительно).
Главная причина — отказаться от тяжелого и ненужного Zend, потому выбирал из фреймворков.
По поводу hhvm — технология слишком молода, чтобы в компании решились бы на ее использование.
По поводу hhvm — технология слишком молода, чтобы в компании решились бы на ее использование.
А фалкон значит не молода, или может у HHVM беда с суппортом, команды нету, фэйсбук их не форсит… А есть еще hippyvm (который основан на PyPy), который по заверению разработчиков в 7 раз быстрее стандартной реализации PHP(правда на синтетических тестах).
Хотя можно рассматривать HHVM и HippyVM как быстрый способ ускорить приложение, так сказать за не дорого, без необходимости переписывать все и вся.
Хотя можно рассматривать HHVM и HippyVM как быстрый способ ускорить приложение, так сказать за не дорого, без необходимости переписывать все и вся.
Сравнивать HHVM и фалкон не корректно. Фалкон это просто framework, и задача была сменить framework. Как известно универсальные методы ускорения никогда не сравнятся с оптимизацией кода.
С оптимизацией кода — сравнится, а с оптимизацией архитектуры — нет. Фалкон — попытка оптимизации архитектуры приложений за счет выноса большей части сервисного слоя на уровень API языка. HHVM, HippyVM, phpng — так же являются глобальными оптимизациями архитектуры самого PHP. Можно так же выкинуть Zend и ORM и получить схожий профит, но поддержка подорожает.
Суть в том что брать фалкон для серьезных проектов довольно сомнительное развлечение (да, профит есть, но увеличиваются риски). С зефиром конечно интереснее, ибо можно постепенно некоторые тяжелые библиотеки портировать и получить довольно ощутимый прирост производительности, но все это в конечном итоге приведет к дроблению языка и инструментов.
Подходы с использованием сторонних реализаций или внедрение JIT в сам PHP дадут более ощутимый профит для всех, так как интерпритируемые языки и создавались для добавления слоя абстракции и независимости от платформы. В противном случае лучше подумать о сегментации проекта и реализации тяжелых его частей на golang/rust/d.
Суть в том что брать фалкон для серьезных проектов довольно сомнительное развлечение (да, профит есть, но увеличиваются риски). С зефиром конечно интереснее, ибо можно постепенно некоторые тяжелые библиотеки портировать и получить довольно ощутимый прирост производительности, но все это в конечном итоге приведет к дроблению языка и инструментов.
Подходы с использованием сторонних реализаций или внедрение JIT в сам PHP дадут более ощутимый профит для всех, так как интерпритируемые языки и создавались для добавления слоя абстракции и независимости от платформы. В противном случае лучше подумать о сегментации проекта и реализации тяжелых его частей на golang/rust/d.
А какие риски увеличиваются выбрав фалькон вместо того же зенда?
«Серьезные проекты» это, извините, фраза ни о чем, что вы подразумеваете под серьезными проектами, какие метрики?
«Серьезные проекты» это, извините, фраза ни о чем, что вы подразумеваете под серьезными проектами, какие метрики?
Проекты хотя бы на 10К+ часов разработки и с большим временем жизни/поддержки, в основном какие-то корпоративные решения, стартапы и т.д. Если выбирать писать приложение требующее высоких нагрузок на PHP+HHVM или просто на PHP+Opcache, и Phalcon я бы выбрал для начала PHP+Opcache и потом бы смотрел в сторону HHVM и подобных решений (тот же HippyVM предлагает коммерческую версию с суппортом), а критичные к нагрузкам вещи переписал бы на golang/rust.
Если вы обнаружите уязвимость, то ничего не сможете с этим сделать — исходники скомпилированы
Унаследовать/переписать класс, поправить уязвимость/баг и использовать его( пока не поправят в фреймворке).
Имея DIC несложно подсунуть свой класс.
Ну и зефир на подходе, да.
Да, как вариант. Но тогда теряется то, ради чего выбирается фреймворк. Вдруг компонент тяжелый окажется? Или его реализация не очевидна и не известно, как нужно реализовать.
Нас поначалу тоже это смущало, но потом мы пришли к выводу, что это надуманная проблема.
Вероятность ошибки в фрейморке достаточно низкая, т.к. он покрыт тестами и находится уже в стабильной версии (мы начинали вообще с версии 0.8 и уже тогда всё работало хорошо).
А если уж вдруг так повезло и вы упёрлись в баг, то его можно пофикисть заменив функции фрейморка на свой или другим фреймворком и отписав в баг-трекер. Или, совсем если уж припёрло, можно залезть в исходники и там поправить и пересобрать.
Но, повторюсь, это очень маловероятно и не стоит на этом зацикливаться. Я в своей практике ещё не встречал проблем, которые совсем никак не решались;)
P.S.: ещё можно добавить, что в самом PHP полно багов, и ничего, работает же
Вероятность ошибки в фрейморке достаточно низкая, т.к. он покрыт тестами и находится уже в стабильной версии (мы начинали вообще с версии 0.8 и уже тогда всё работало хорошо).
А если уж вдруг так повезло и вы упёрлись в баг, то его можно пофикисть заменив функции фрейморка на свой или другим фреймворком и отписав в баг-трекер. Или, совсем если уж припёрло, можно залезть в исходники и там поправить и пересобрать.
Но, повторюсь, это очень маловероятно и не стоит на этом зацикливаться. Я в своей практике ещё не встречал проблем, которые совсем никак не решались;)
P.S.: ещё можно добавить, что в самом PHP полно багов, и ничего, работает же
Также нет никаких красивостей с цветными текстами, фонами, так что разукрасить консоль радугой не получится
Консоль можно легко раскрасить радугой самостоятельно: www.if-not-true-then-false.com/2010/php-class-for-coloring-php-command-line-cli-scripts-output-php-output-colorizing-using-bash-shell-colors/
Мне очень нравится что фалкон следует логике написания функций PHP:
public function Adapter::update($table, $fields, $values, $whereCondition=null, $dataTypes=null) bool
public function Adapter::insert($table, $values, $fields=null, $dataTypes=null) bool
public function Adapter::update($table, $fields, $values, $whereCondition=null, $dataTypes=null) bool
public function Adapter::insert($table, $values, $fields=null, $dataTypes=null) bool
… однако проблема была не с Phalcon, а с Nginx, которому стало тяжело держать большое количество соединений…
nginx не в состоянии держать ~500 соединений? Что-то невероятное. Можно поподробнее?
Нет, nginx не справлялся с 25к соединений. 500 соединений было открыто на тестовой ноде, где для него проблем не было.
Тюньте ваш nginx. 25к он может выдавать на обычном относительно новом офисном компе.
Собственно это я и имел в виду в статье, как следующий этап оптимизации.
Следующая статья будет целиком посвящена открытию директивы worker_connections? =)
del
Имею опыт с phalconphp на крайне простом проекте, во всём согласен с автором, кроме этого
Я напоролся на кучу багов и просто недоработок, которые приходилось хитро обходить. Например
отношение one-to-one при определённых простых условиях вызывает ошибку времени выполнения
не работают стандартные для фреймворка флаги кеширования, если запрос содержит агрегирующие функции
для отношения many-to-many не работает флаг reusable, из-за этого ORM выполняет запрос в базу на каждое обращение к одному и тому же полю модели
в случае many-to-many не работает удаление связи между моделями
Фреймворк нисколько не показался сырым — никаких багов с функционалом замечено не было.
Я напоролся на кучу багов и просто недоработок, которые приходилось хитро обходить. Например
отношение one-to-one при определённых простых условиях вызывает ошибку времени выполнения
не работают стандартные для фреймворка флаги кеширования, если запрос содержит агрегирующие функции
для отношения many-to-many не работает флаг reusable, из-за этого ORM выполняет запрос в базу на каждое обращение к одному и тому же полю модели
в случае many-to-many не работает удаление связи между моделями
Sign up to leave a comment.
Phalcon Framework на продакшене