Я правильно понимаю, что ваши тесты были добавлены в код оригинального бенчмарка только относительно недавно (пару месяцев назад) и вы займёте какое-то место в общем рейтинге только где-то через полгода?
Все верно, ждем следующий раунд.
Если до swoole, который на C++/C, будет сложно угнаться, то достигнуть результатов workerman, который написан на чистом PHP, это уже вполне реально.
Я не уверен что в принципе возможно обогнать чистый Swoole на полноценном фреймворке с ORM и шаблонами. Если смотреть на пример Symfony+Swoole то отставание на 29%, а не в 10 раз. До самого дальнего фреймворка на Swoole/Workerman отставание в 4-5 раз, чего трудно добиться без жертв со стороны архитектуры.
Такое ощущение, что писатель документации взял за цель минимизировать количество текста, оставив только чистую эссенцию новой информации.
Так и есть, покрыть такое количество материала достаточно сложно с первого раза.
Ещё бы реквестировал доку или пример работы не через php-cli, а через php-cgi в командной строке. В теории оно должно работать, на практике пока сложновато продраться через дебри.
CGI интеграцию еще не делали.
Ещё вопрос, почему внутри используется zend diactaros, а не laminas diactaros? То есть ругающийся composer update иногда настораживает.
В процессе переключения, ничего не хотим сломать.
Ещё вопрос, а возможно ли заменить тот же diactaros на другой? например, более быстрый Nyholm\Psr7?
Без проблем, фреймворк как раз и использует Nyholm по умолчанию.
Ещё вопрос, а не рассматривали подход с fasthhttp? В теории, так как воркеров ограниченное количество, можно сделать ± zero memory allocation работу, или хотя бы минимизировать это дело.
Есть в пайплайне, но большого прироста не ожидаем так как боттлнек на стороне PHP.
Работа с переключением контекста запроса сделана на уровне ядра контейнера, большинство критичных сервисов иммутабельны, работа со стеком вместо работы с событиями. Все познавалось на горьком опыте и верифицировалось на живых проектах.
Плюсы и минусы будут примерно такие же как у Swoole. Придется биндится на АПИ модуля и собирать его с nginx (php встраивается). Работать будет быстрее, модифицировать будет сложнее.
В приложении на spiral — нет, мы изначально разработали архитектуру для работы в режиме демона. Насчет существующего приложения не скажу, зависит от фреймфорка и вашего кода.
Привет, это именно PHP фреймфорк, так что с точки зрения PHP разработчика ничего не меняется. Golang компилируется в бинарный файл и не беспокоит вас своим присутствием.
Скорость на синтетических тестах — это, конечно, хорошо, но как обстоят дела с памятью и отказоустойчивостью?
Все хорошо, мы написали rr как раз для того чтобы приложения выдерживали резкие нагрузки. Память зависит от количества воркеров и объема вашего приложения. Про поведение сервера под нагрузками можно почитать тут — https://habr.com/ru/post/431818/ (на ядре Symfony).
Я так и не понял, в чём преимущество вашего фреймворка перед Symfony, Laravel или Phalcon? Symfony мне нравилась тем, что в ней всё работает, как в доках, пусть даже они и не всегда хорошие, а код на ней получается очень чистым, без лишнего хлама. Laravel простая, как пять копеек, даже не смотря на отвратительную производительность, полный треш в пакетах и чудачества eloquent, у неё всё равно есть своя область применения.
Мы больше склоняемся к модели Symfony, но используем работу как со стеком (middleware) Laravel. Код не сильно отличается от этих фреймворков, и, пожалуй, не должен отличаться. Плюсом можно назвать то что для запуска даже сложного приложения вам не потребуется ставить зоопарк инструментов.
У вас я открыл быстрый старт в документации, а там мне предлагают писать обработку аннотаций роутера или пользоваться каким-то странным классом с шаблонным кодом. Я что-то не так понял или и правда нужно нажимать так много лишних кнопок?
Нет не нужно, просто аннотированный роутинг самый частый вопрос на который пока нет расширения из коробки, вот его и включили в обзорную статью. В самом начале упоминается что роутинг можно определять руками. Постараемся отполировать данную часть.
Вы пишете, что в основном в фреймворк используется в b2b, но я так и не смог придумать ни одной причины, почему там нужно использовать интеграцию с го и не хватит просто php или питона, например. На каких задачах он сможет полноценно раскрыть свой потенциал?
Сейчас мы пишем в основном распределенные проекты, в таких приложениях вы можете получить максимальную пользу от фреймворка за счет встроенных инструмент.
Из интересного сейчас есть Laminas, в частности, Mezzio(бывш. Expressive), с миддлварами из коробки и без http-kernel с его противными «ивентами».
Вот бы был очень быстрый и компонентный PSR-* фреймворк. С RAD, но без магии. C нормальной ORM и инструментарием для горизонтального масштабирования. Желательно чтобы поддерживался компанией и имел 600 страниц документации. :D
В Cycle ORM выборки сделаны похожим образом. Только учитывается отсутствие уникальности названий колонок, дедупликация родительских записей, а также возможность вытягивать часть данных внешним запросом используя ссылочное дерево.
Имелось ввиду что там два набора бенчмарков. Это разные проекты.
Swoft уже есть, ориентировочно в два раза быстрее спирали.
Только оригинальный репозиторий вот этот — https://github.com/TechEmpower/FrameworkBenchmarks
Все верно, ждем следующий раунд.
Я не уверен что в принципе возможно обогнать чистый Swoole на полноценном фреймворке с ORM и шаблонами. Если смотреть на пример Symfony+Swoole то отставание на 29%, а не в 10 раз. До самого дальнего фреймворка на Swoole/Workerman отставание в 4-5 раз, чего трудно добиться без жертв со стороны архитектуры.
Именно так оно и задумывалось. Плюс мы аунтифицируем пользователей еще до того как они достучатся до приложения.
Можно, но для этого придется модифицировать протокол. Поддержка асинхронных клиентов задумана в 3й версии.
Привет,
Работа с переключением контекста запроса сделана на уровне ядра контейнера, большинство критичных сервисов иммутабельны, работа со стеком вместо работы с событиями. Все познавалось на горьком опыте и верифицировалось на живых проектах.
Ссылки на бенчмарки доступны в статье, самим удивительно. Вот последние результаты: https://www.techempower.com/benchmarks/#section=test&runid=c7013ea3-22c9-44c1-864f-949509d78e0c&hw=ph&test=fortune&l=zik073-1r&c=6
Само собой синтетика не показатель, но результаты не в пользу Phalcon.
Плюсы и минусы будут примерно такие же как у Swoole. Придется биндится на АПИ модуля и собирать его с nginx (php встраивается). Работать будет быстрее, модифицировать будет сложнее.
Привет, трудно судить по бенчмарку учитывая что там чистый PHP — https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/PHP/php-ngx/app.php
Достаточно большой оверхед создают ORM и другие части фреймворков, так что такое сравнение не совсем честное.
В приложении на spiral — нет, мы изначально разработали архитектуру для работы в режиме демона. Насчет существующего приложения не скажу, зависит от фреймфорка и вашего кода.
Это делает сам фреймворк за ваc.
Привет, это именно PHP фреймфорк, так что с точки зрения PHP разработчика ничего не меняется. Golang компилируется в бинарный файл и не беспокоит вас своим присутствием.
Спасибо за большой комментарий.
Все хорошо, мы написали rr как раз для того чтобы приложения выдерживали резкие нагрузки. Память зависит от количества воркеров и объема вашего приложения. Про поведение сервера под нагрузками можно почитать тут — https://habr.com/ru/post/431818/ (на ядре Symfony).
Мы больше склоняемся к модели Symfony, но используем работу как со стеком (middleware) Laravel. Код не сильно отличается от этих фреймворков, и, пожалуй, не должен отличаться. Плюсом можно назвать то что для запуска даже сложного приложения вам не потребуется ставить зоопарк инструментов.
Нет не нужно, просто аннотированный роутинг самый частый вопрос на который пока нет расширения из коробки, вот его и включили в обзорную статью. В самом начале упоминается что роутинг можно определять руками. Постараемся отполировать данную часть.
Сейчас мы пишем в основном распределенные проекты, в таких приложениях вы можете получить максимальную пользу от фреймворка за счет встроенных инструмент.
Именно так, придётся писать приложения как это принято в любом другом языке программирования.
Задача фреймворка как раз упростить разработку таких приложений и избавить вас от большинства багов.
Привет, у нас есть дискорд сервер. Ссылка странице репозитарий. Телеграм ещё не завели, но уже активно думаем в эту сторону.
Это не ирония (https://spiral.dev/). Через 2-3 недели анонсируем официально.
Вот бы был очень быстрый и компонентный PSR-* фреймворк. С RAD, но без магии. C нормальной ORM и инструментарием для горизонтального масштабирования. Желательно чтобы поддерживался компанией и имел 600 страниц документации. :D
В Cycle ORM выборки сделаны похожим образом. Только учитывается отсутствие уникальности названий колонок, дедупликация родительских записей, а также возможность вытягивать часть данных внешним запросом используя ссылочное дерево.