Comments 68
UFO just landed and posted this here
производительности не сильно прибавляет, а нажать в отладке Step Into на строке с вызовом фреймворка нельзя.
Троллинг? Более чем в 10 раз производительнее Symfony2 и в 6 раз меньше потребление памяти.
Что касается отладки, это уже задача разработчиков фреймворка. Тот же Sf2 не многие отлаживают, проще зарепортить issue
UFO just landed and posted this here
С чего вы взяли, что разные задачи?
Про узкое место во внешних сервисах и БД я как-то уже устал слушать — возьмите любое приложение и пройдитесь профайлером, потом мы сможем конструктивно обсудить их узкие места.
Что касается люмена, то фалкон в 4 раза производительнее, и да, люмен позиционирует себя как микрофреймворк в отличие от фалкона
Про узкое место во внешних сервисах и БД я как-то уже устал слушать — возьмите любое приложение и пройдитесь профайлером, потом мы сможем конструктивно обсудить их узкие места.
Что касается люмена, то фалкон в 4 раза производительнее, и да, люмен позиционирует себя как микрофреймворк в отличие от фалкона
> Сравните с lumen.laravel.com
С ним сравнивать надо phalcon micro mvc, чтобы было честно.
С ним сравнивать надо phalcon micro mvc, чтобы было честно.
Мы же с вами понимаем, что обычно в проекте по мимо самого фреймворка куча дополнительных модулей, подтянутых с помощью composer, плюс наш код, а значит скорость работы не будет x10.
Фалкон вполне себе самодостаточен: на большинство рядовых задач можно обойтись минимум сторонних библиотек.
Что касается своей бизнес-логики, то Фабьен сам признавался, что основная нагрузка при обработке запроса ложится на фреймворк (инициализацию), он пытается вести какие-то работы в этом направлении, но, как видим, пока результатов нет, и оверхед этот остается
Что касается своей бизнес-логики, то Фабьен сам признавался, что основная нагрузка при обработке запроса ложится на фреймворк (инициализацию), он пытается вести какие-то работы в этом направлении, но, как видим, пока результатов нет, и оверхед этот остается
Скажите, вы сами видели проекты, в которых по мимо самого фреймворка и вашего кода нет ничего дополнительно поставленного через composer? Речь не о проектах уровня «Hello world!».
Я о том, что понятно — сам фреймворк быстрый, sf2 курит в сторонке, все дела… Но в реальности все немножко иначе и надеяться на x10 ускорение не приходится.
Я о том, что понятно — сам фреймворк быстрый, sf2 курит в сторонке, все дела… Но в реальности все немножко иначе и надеяться на x10 ускорение не приходится.
Понятно, что будет какое-то падение, но я еще раз повторяю, большую часть времени занимает инициализация фреймворка, сторонние либы чаще всего включаются частично в зависимости от страниц. Пусть ускорение будет x5-x8 — вас такой ответ устроит? :D
Я не замерял… А раз так — конкретных иксов я не скажу и устроить ваш ответ меня не может без прогнанных тестов. Я говорил лишь о том, что x10 unreal в реальном мире.
Ну так и симфони гибче и масштабнее, там больше кода инициализации, различных проверок.
Все эти цифры приблизительны, но глупо их игнорировать
Все эти цифры приблизительны, но глупо их игнорировать
Кто сказал, что я игнорирую их?! Phalcon 2 крут в плане скорости, но сейчас речь не про это. Речь про то, что важно здраво оценивать то, что напишут тестеры и понимать, что синтетика никогда не даст реальных результатов и поэтому важно думать прежде чем выбирать тот или иной фреймворк для вашей задачи. Не более.
Мы, не используем Composer. Не вижу смысла тянуть в нормальный проект все эти зависимости.
Если Вы пишете код с правилом — «лишь бы было и работало», тогда композер подойдёт и ваш подход подойдёт и sf2 в том числе.
Но в сколько нибудь нагруженном проекте Ваш подход испытает очень большие трудности.
Если Вы пишете код с правилом — «лишь бы было и работало», тогда композер подойдёт и ваш подход подойдёт и sf2 в том числе.
Но в сколько нибудь нагруженном проекте Ваш подход испытает очень большие трудности.
Я правильно понимаю вы противник composer way? Каким путем идете вы?
Можете рассказать какие именно огромные трудности испытает нагруженный проект (серьезно интересно)?
По моему composer как раз не для «лишь бы было и работало», а как раз для того, чтобы заюзать удобный интеллектуальный менеджер «пакетов», в котором есть все для дальнейшей жизни проекта (install, upgrade, remove, dependencies).
Можете рассказать какие именно огромные трудности испытает нагруженный проект (серьезно интересно)?
По моему composer как раз не для «лишь бы было и работало», а как раз для того, чтобы заюзать удобный интеллектуальный менеджер «пакетов», в котором есть все для дальнейшей жизни проекта (install, upgrade, remove, dependencies).
Интереcные вопросы, получается короткое интервью, я не являюсь автором проекта и его архитектором по сути, но всё же на некоторые вопросы могу ответить точно.
1. Совершенно верно, мы не используем composer, весь код проекта «изобретается заново», где десятки слоёв абстракций заменяются одним простым и удобным, целевым решением (функцией или классом).
2. У каждого свои трудности, в нашем случае — это средства :) Их всегда — не достаточно, мы не может взять и прыгнуть через голову, приходится идти небольшими шагами.
3. Менеджер пакетов и автоматический контроль зависимостей требует большое количество ресурсов, а мы не любим их тратить впустую :) Приведу пример: мы ищем в композере класс, который позволял бы сделать crop картинки и находится класс, который позволяет делать с изображением всё что угодно, но нам не нужен этот огромный класс, нам нужен только crop с уже известной степенью сжатия и известным путём для файла, а так же алгоритмом «вырезания картинки». Таким образом мы выбрасываем «удобный» класс композера на 1500 строк кода, а так же 10 уровнями абстракции и заменяем его функцией на 150/200 строк.
1. Совершенно верно, мы не используем composer, весь код проекта «изобретается заново», где десятки слоёв абстракций заменяются одним простым и удобным, целевым решением (функцией или классом).
2. У каждого свои трудности, в нашем случае — это средства :) Их всегда — не достаточно, мы не может взять и прыгнуть через голову, приходится идти небольшими шагами.
3. Менеджер пакетов и автоматический контроль зависимостей требует большое количество ресурсов, а мы не любим их тратить впустую :) Приведу пример: мы ищем в композере класс, который позволял бы сделать crop картинки и находится класс, который позволяет делать с изображением всё что угодно, но нам не нужен этот огромный класс, нам нужен только crop с уже известной степенью сжатия и известным путём для файла, а так же алгоритмом «вырезания картинки». Таким образом мы выбрасываем «удобный» класс композера на 1500 строк кода, а так же 10 уровнями абстракции и заменяем его функцией на 150/200 строк.
Т.к. суперкласс в index.php? Насколько «большой» ваш проект? ))
Опыт показывает, что сперва берется функция crop, потом через месяц попросили ввести rotate, потом scale и через пол года вы написали ту самую библиотеку, только криво, на костылях, тогда как та либа покрыта тестами, проверена сообществом 100500 раз и используется в топовых проектах. Пройдено уже ;D
Опыт показывает, что сперва берется функция crop, потом через месяц попросили ввести rotate, потом scale и через пол года вы написали ту самую библиотеку, только криво, на костылях, тогда как та либа покрыта тестами, проверена сообществом 100500 раз и используется в топовых проектах. Пройдено уже ;D
Если проект одноразовый, то возможно и так прокатывает. Потом проект приходит к кому-то на support и заказчик слышит волшебную фразу: «Мы щас вам тут все перепишем на %framework_name%»
Не надо кидаться из крайности в крайность, нет никакого супер index.php :) Большой ли, не знаю что для Вас большой проект, в php файлах насчитал 75000 строк, фреймворка — нет, все базовые классы реализованы в 2-3 тысячах строк.
Rotate не делаем, если понадобится добавить 1-2 строку кода с поворотом угла будет не так уж и сложно, итого получаем 30 строк кода включая комментарии, для древнющего gd :)
Rotate не делаем, если понадобится добавить 1-2 строку кода с поворотом угла будет не так уж и сложно, итого получаем 30 строк кода включая комментарии, для древнющего gd :)
Я не хотел кидаться в крайности :) Просто на моем текущем месте работы (когда я пришел туда) четко сказали, что надо писать на статике, типо быстро и просто и т.д. С тех пор прошло уже 4 года, конечно, и сейчас часть того ужасного легаси уже переписана, но часть осталась, как шрам на теле :)
И по опыту опять же, поначалу так и было, что мол проще написать 1 функцию, чем искать либы и т.д. В итоге все это обрастало костылями, никаких абстракций же, лишние усложнения и т.д.
А я по натуре такой программист, который ищет готовые решения всегда. Я велосипед писать буду только если он спасет от падения метеорита )) и то скорей всего сперва загуглю… Поэтому для меня вопрос болезненный ))
И по опыту опять же, поначалу так и было, что мол проще написать 1 функцию, чем искать либы и т.д. В итоге все это обрастало костылями, никаких абстракций же, лишние усложнения и т.д.
А я по натуре такой программист, который ищет готовые решения всегда. Я велосипед писать буду только если он спасет от падения метеорита )) и то скорей всего сперва загуглю… Поэтому для меня вопрос болезненный ))
Если производительность так уж важна, то зачем вообще писать на PHP? Си ваше все. В ином случае получается экономия на спичках.
Менеджер пакетов и автоматический контроль зависимостей требует большое количество ресурсов, а мы не любим их тратить впустую :)
Вы имеете ввиду ресурсы компьютера или человеческие ресурсы? Поскольку composer лишь средство для установки PHP библиотек, ваша фраза звучит как «все, что написали другие, по умолчанию раздуто и медленно». Или мне показалось?
Таким образом мы выбрасываем «удобный» класс композера на 1500 строк кода, а так же 10 уровнями абстракции и заменяем его функцией на 150/200 строк.
Я правильно понимаю, что вы исповедуете NIH философию?
Возможно речь про ресурсы шла в разрезе обертки, которую создает composer для autoload'а всех штуковин из vendor. Поправьте если не так.
Имею ввиду ресурсы компьютера.
нет, вы не правильно понимаете, мы используем философию целевого программирования, когда код пишется для какой-то уже известной цели, а не для абстрактных, возможных углов его применения.
Как обычно для хабры, стянулись гуру домашнего программирования и перевернули всё так, как им удобно, считая только их подход правильным, всё будет хорошо, никуда Ваш композер не денется, как писали 90% людей на нём или используя его и PSR-4, так и будут дальше.
Однако — есть проекты, в которых всё это не нужно, не нужно всех под одну гребёнку, каждой задаче должно быть своё решение, впрочем, зачем я это всё объясняю, думаю даже начинать не стоило.
нет, вы не правильно понимаете, мы используем философию целевого программирования, когда код пишется для какой-то уже известной цели, а не для абстрактных, возможных углов его применения.
Как обычно для хабры, стянулись гуру домашнего программирования и перевернули всё так, как им удобно, считая только их подход правильным, всё будет хорошо, никуда Ваш композер не денется, как писали 90% людей на нём или используя его и PSR-4, так и будут дальше.
Однако — есть проекты, в которых всё это не нужно, не нужно всех под одну гребёнку, каждой задаче должно быть своё решение, впрочем, зачем я это всё объясняю, думаю даже начинать не стоило.
зачем я это всё объясняю, думаю даже начинать не стоило.
Почему не стоило? У вас есть позиция, почему бы ее не разъяснить?
Мне непонятно, каким образом отказ от composer экономит ресурсы компьютера. Непонятно также, каким образом в разработке помогает NIH-принцип.
И мне бы хотелось понять вашу точку зрения.
Вам везет)) Серьезно!
Мой опыт и опыт всех моих знакомых разработчиков показывает, что обычно у нас нет времени на трюки с выпилкой только нужного функционала из подключаемых либ. Я о том, что скажем в проекте с 20-30 зависимостями (мы понимаем, что это не предел для долго играющих проектов) из composer у нас просто физически нет времени на описанные выше действия.
Часто приходится быстро находить решения для задач, чтобы клиент остался доволен и проект завершился во время. Конечно, это вопрос менеджмента на проекте и возможно здесь есть над чем задуматься. Хотя опять же ваш подход как я думаю в теории должен сильно увеличивать сроки, даже с учетом, что все ходовые штуки вы уже давно выпилили и юзаете от проекта к проекту. Или нет?
Мой опыт и опыт всех моих знакомых разработчиков показывает, что обычно у нас нет времени на трюки с выпилкой только нужного функционала из подключаемых либ. Я о том, что скажем в проекте с 20-30 зависимостями (мы понимаем, что это не предел для долго играющих проектов) из composer у нас просто физически нет времени на описанные выше действия.
Часто приходится быстро находить решения для задач, чтобы клиент остался доволен и проект завершился во время. Конечно, это вопрос менеджмента на проекте и возможно здесь есть над чем задуматься. Хотя опять же ваш подход как я думаю в теории должен сильно увеличивать сроки, даже с учетом, что все ходовые штуки вы уже давно выпилили и юзаете от проекта к проекту. Или нет?
Да, сроки большие, всё связано с тем, что это не аутсорсинг проект, задачи решаются постепенно по мере их необходимости, код пишется целевой максимально короткие сроки, главный упор на бекенде — бытсродействие, на фронтенде — функционал.
А для аутсорсинг проектов конечно же нет смысла изобретать что-то, можно брать всё готовое, лишь бы работало)))
А для аутсорсинг проектов конечно же нет смысла изобретать что-то, можно брать всё готовое, лишь бы работало)))
Для этого надо исключить инициализацию при каждом запросе (отказаться от php always die) и использовать подход одноразовой инициализации как в node-js: phpDaemon, reactphp, prefork.
Я просто оставлю это здесь
github.com/kenjis/php-framework-benchmark
github.com/kenjis/php-framework-benchmark
Хотелось бы увидеть сравнение скажем с Django.
Как часто заказывают hello world проекты? почему?
В большом проекте будут разного вида кэши (не видел пока ни одного крупного проекта без кэширования). И symfony2 выдаст уже совсем другие результаты.
А если к ней прикрутить reactphp (по умолчанию никаких утечек памяти в симфе — проверяли), то можно будет уже и на верхних строках оказаться.
Интересно, если бы кто такой тест сделал, у кого есть время и скиллы потестировать?
В большом проекте будут разного вида кэши (не видел пока ни одного крупного проекта без кэширования). И symfony2 выдаст уже совсем другие результаты.
А если к ней прикрутить reactphp (по умолчанию никаких утечек памяти в симфе — проверяли), то можно будет уже и на верхних строках оказаться.
Интересно, если бы кто такой тест сделал, у кого есть время и скиллы потестировать?
Это если читстый фреймворк запускать — будет такой показатель.
Если написать своего кода на PHP сверху да подключить несколько компонентов Symfony или Zend для решения задач и все, скорости уровнялись.
Для микро фреймворков то же самое.
Если написать своего кода на PHP сверху да подключить несколько компонентов Symfony или Zend для решения задач и все, скорости уровнялись.
Для микро фреймворков то же самое.
Но при этом нужна знания Zephir, который никто не знает
Zephir, судя по документации настолько похож php, что любой php-программист разберется в нем очень быстро, в то время как научиться писать расширения на Си намного сложнее, особенно для людей плохо знающих Си
sudo ./install
Вот за такие рекомендации хоть бери руки отрывай. Потом же его не выпилишь с системы. Писал разработчикам давным давно — игнорируют.
Сделали бы хоть пару пакетов — deb и rpm, пусть даже компилируются при установке (как Java ставится с ppa в Ubuntu — в процессе установки скачивается, распаковывается куда нужно и конфигурируется), но чтобы можно было легко поставить, а потом легко снести под корень.
Уже изобрели эту штуку — ok google what is checkinstall?
Да, я в курсе (когда-то пробовал, так и не получилось собрать, хотя давно это было), а вот разработчики по ходу нет.
Да и забить вообще на него. Docker спасёт отца русской демократии.
Я собирал под Docker его (не хочется так мусорить в рабочей системе), так на хосте полученное расширение (hello world) приводило постоянно к segmentation fault, а я-то хотел один часто используемый класс переписать…
Значит где-то что-то не так. Иссуя на гитхабе создана?
Да, сразу несколько по разным поводам, но так ничего и не получил в ответ: github.com/phalcon/zephir/issues/663
Зато метку «not tested» поставили через 27 дней со дня репорта. Странное отношение…
Зато метку «not tested» поставили через 27 дней со дня репорта. Странное отношение…
На самом деле, как один из активных контрибьюторов могу сказать, что разбирать баги под zephir самое не приятное занятие.
Особенно радует, когда разработчики не следуют описанной процедуре сообщения о багах:
github.com/phalcon/zephir/blob/master/CONTRIBUTING.md#bugs
Помимо описанных пунктов, желательно сразу добавить C-код сгенерированный/ссылку на проект/PR с тестом.
Особенно радует, когда разработчики не следуют описанной процедуре сообщения о багах:
github.com/phalcon/zephir/blob/master/CONTRIBUTING.md#bugs
Помимо описанных пунктов, желательно сразу добавить C-код сгенерированный/ссылку на проект/PR с тестом.
Хорошая штука, но последняя версия вышла 6 лет назад. Оно работает нормально?
4 месяца. @sее checkinstall.izto.org
Куча софта нет в пакетах — это нормально, по тому что под это дело надо выделять человека чтобы он этим занимался и поддерживал, по этому логично что они пишут фреймворк, а если есть желающие помочь делом то они участвуют.
А для сборки пакетов «для личных нужд» есть достаточно инструметов: fmp, checkinstall…
А для сборки пакетов «для личных нужд» есть достаточно инструметов: fmp, checkinstall…
Сделали бы хоть пару пакетов
Все же есть phalconphp.com/en/download, только еще не успели собрать под версию 2.0
Интересно, а как Zephir подружить с другими модулями или библиотеками, например использовать Redis или SQLite? При быстром обзоре документации ничего подобного не заметил…
Вопрос — а zephyr расширение можно использовать без установленного phalkonphp?
Ну то есть собрать его, и перенести .so
Ну то есть собрать его, и перенести .so
Насколько эта штука Testable? И как удобно писать тесты под код с Phalcon?
Все нормально, а в чем Вы видите проблему?
Извините, я не вижу проблему. Просто интересует есть ли уже готовые практики на этот счет. Скорее про community power вопрос.
Все тоже самое, что и в других фреймворках, просто часть кода поставляется бинарником в виде экстеншна (например, как встроенный в PHP класс DateTime). Для IDE есть devtools, с ними нормально работает автоподстановка и быстрый доступ к докам.
По опыту пиления проекта на Флаконе (как мы его называем промеж себя) скажу, что иногда бывают сложности. Ясное дело: F7 не сделаешь, внутрь кода не попадешь. Потому довольно часто приходится лезть собственно в исходники Флакона (благо написано легко и непринужденно, так что читать нетрудно). Потому версия 2 в этом смысле выглядит явно привлекательнее — именно в силу того, что написана на более read-friendly языке. Сообщество слабое, процентов на 70 приходилось искать ответ своими силами. Официальный форум содержит в основном весьма элементарные вещи, а время, чтобы ждать ответ, не всегда есть. Да, еще большой минус — разработчики весьма фривольно относятся к обратной совместимости. В версии 1.3.* по сравнению с версией 1.2.* поменяли набор аргументов в паре методов (на память только какой-то log formatter приходит), что реально затрудняет переход на новую версию, когда уже есть работающий проект на проде.
Вполне себе ок, конечно, иногда не удобно, что не видно полноценного стектрейса при ошибках, но по идее Phalcon DevTools как-то решают эти вопросы. Во всем остальном — тестируется как любой другой проект. Кроме того, есть модуль для тестирования для Codeception с демо-проектом: codeception.com/docs/modules/Phalcon1
Ах, ну да, следует обновить его до Phalcon2 :)
Ах, ну да, следует обновить его до Phalcon2 :)
Sign up to leave a comment.
Phalcon 2 вышел