В бенчах RR-Swoole-Franken обычно все допускают одни и те же ошибки в настройках RR: - не выключают логи и тестирую пропускную способность stdout. - не устанавливают protobuf и теряют очень много на (де)сериализации протобафов. При тестировании пустых эндпоинтов это существенно. - не тестируют разные важные опции типа кол-ва воркеров (относится ко всем серверам)
Несмотря на то, что Swoole в HTTP будет всегда объективно быстрее других (если только RR или Франкен не перепишут с go на что-то без интеропа), всё-таки хотелось бы видеть какую-то объективность в цифрах.
Короче, рекомендую читать документацию к серверам, чтобы устанавливать и настраивать их правильно, а не полагаться на дефолты Octane.
Компании, которые указывают вилки выше рынка тоже, как правило, ведут нечестную игру:
Компании выгодно показать своим инвесторам, что дела у неё хорошо, мол "мы расширяемся, вилки высокие, хайтек"
Компании навязывать свои технологии разработчикам, рассказывая про них под большой вилкой. Например: - ООО Митрикс нанимает за 400К разработчиков разрабатывать продукты на Митрикс ЦРМ, требование: знание Митрикс ЦРМ. - Все остальные вакансии без вилок или за 200К разрабатывать на популярном стеке И условный Васян посмотрит, почешет репу, и пойдёт изучать Митрикс ЦРМ. Через полгода он знает и распространяет эту технологию.
При этом, такие компании могут даже не хотеть новых разрабов и будут заваливать их на собесах, мывамперезванивать и в фоне набирать список достойных кандидатов на всякий случай.
А так да, статья нормальная, буду практиковать. Опоздание на 5 минут -- нормальная штука, как и растяигвание митингов свыше запланированного времени (от того и возникают опоздания на следующий митинг)
Я бы также рекомендовал проверять знания в ширину на стыке стеков.
Например, бэкендер обязательно должен знать минимум две технологии фронтента, чтобы разговаривать с фронтенд-разработчиками на общем языке.
Точно также фронтендер должен знать бэк. Нафига нужен фронтендер, который не знает базы данных и всё с ними связанное? Ему от туда, между прочим, на фронт данные льются! Должен знать PHP и его туллинг, чтобы понимать, на что рассчитвать со стороны бэка. И на случай, если надо что-то там подфиксить, пока пехапешник перекрашивает кнопку по другой задаче.
Можно, кстати, попробовать заменить $headerLine = socket_read($this->acceptedSocket, 1); на использование socket_recv() и забенчить снова. Сдаётся мне, на этом можно здорово сэкономить
Под многие вещи у amphp есть асинхронные драйвера. Можно сразу туда идти и набирать. Или сразу на AMP писать :) Однако вендорные штуки или ORM переписывать всё-равно не будешь ¯\_(ツ)_/¯ . А там и PDO, и чего только нет.
Ещё одна большая проблема — протекание контекста. Например один общий Unit of Work или Entity Manager. В некоторых случаях даже разные инстансы контейнера на отдельный запрос не помогут.
Реализованы в какой-то мере HTTP, WebSocket, SMTP.
Я бы, конечно, не рекомендовал на PHP писать серверы прям на замену RoadRunner, FPM и т.д., как минимум потому что:
всегда что-то будет работать в блокирующем режиме (работа с файловой системой, STDIN/OUT, PDO или вендорный пакет)
пыховский zval всегда будет тормознее примитивов в C/Go/Rust...
Но погружаться в эту тему всё-равно как-то надо. Для лёгкого старта можно попробовать phasync, который поможет юзать файберы в ограниченном контексте на готовом проекте. Останется только найти, что параллелить :) говорят под доктрину есть async драйвера
...->findOne() ?? throw new NotFoundException(); ¯\_(ツ)_/¯
Вспомнилась статья, в которой чувак рекомендует всегда использовать firstOrFail() . А когда надо выкинуть своё исключение, то он оборачивает в try/catch. Причём в его кейсе даже без $previous.
Быстрая разработка на Laravel подразумевает, что человек знает все эти фасады и сокращения. Поэтому, сдаётся мне, вчерашние студенты одинаково медленно и отвратительно решат задачу на любом фреймворке :)
@CodeMaster125 может у вас какой-то более конкретный вопрос по дебажинью продакшена? Если проблема на конкретном сервере, то, наверное, дело уже не в коде и профайлер тут не поможет?
Хоть номинально все RPC вызовы и проходят через один Temporal кластер, но гибких возможностей выстраивать политику кто и что может, вроде как, нельзя. Поэтому сервисы практически бесконтрольно могут дёргать друг-друга.
Этот недостаток можно попробовать решить интерцепторами. Тут сложность возникнет с тем, чтобы описать их на всех языках, на которых написаны Workflow. Но если у вас только PHP, то аля deptrac|nocolor на интерцепторах - интересный вызов :) Интерцепторы уже можно щупать, установив SDK версии 2.7.0@dev.
Есть ли способ без хаков уменьшить гигантскую панель слева (без изменения общего масштаба)?
Сам предпочитаю PHPStorm, т.к. VSCode с любым количеством плагинов не дотягивает до возможностей IDE. Однако скорость работы VSCode (особенно в WSL) иногда подкупает. В мире PHP, кстати, VSCode вряд ли займёт лидирующую позицию.
Ну, Yii 2 проблем скорее всего не создаст - там давно фичефриз и очень широкий диапазон поддерживаемых версий PHP.
Проблем стоит ждать от сторонних библиотек и, естественно, от кода проекта. В последнем не редки такие сюрпризы, что аннотации с типами отличаются от фактического типа. Тогда ректорить такой проект надо с чательной ручной модерацией.
Согласен с тем, что лучше обновлять поэтапно. Каждый этап - это `composer up` + `composer why-not php x.x`. Если есть блокеры - разбираться с ними, потом с кодом проекта.
Это уже можно считать распределённым монолитом.
А вообще, если относиться к переменным, как к подам, то каждая функция будет кластером.
Всё-таки важно говорить общей терминологией и оперировать принятыми понятиями, а не уходить в философию.
Я тоже не понял, про что статья. Есть рассуждения, но они быстро заканчиваются ничем.
В бенчах RR-Swoole-Franken обычно все допускают одни и те же ошибки в настройках RR:
- не выключают логи и тестирую пропускную способность stdout.
- не устанавливают protobuf и теряют очень много на (де)сериализации протобафов. При тестировании пустых эндпоинтов это существенно.
- не тестируют разные важные опции типа кол-ва воркеров (относится ко всем серверам)
Несмотря на то, что Swoole в HTTP будет всегда объективно быстрее других (если только RR или Франкен не перепишут с go на что-то без интеропа), всё-таки хотелось бы видеть какую-то объективность в цифрах.
Короче, рекомендую читать документацию к серверам, чтобы устанавливать и настраивать их правильно, а не полагаться на дефолты Octane.
blackend
Компании, которые указывают вилки выше рынка тоже, как правило, ведут нечестную игру:
Компании выгодно показать своим инвесторам, что дела у неё хорошо, мол "мы расширяемся, вилки высокие, хайтек"
Компании навязывать свои технологии разработчикам, рассказывая про них под большой вилкой.
Например:
- ООО Митрикс нанимает за 400К разработчиков разрабатывать продукты на Митрикс ЦРМ, требование: знание Митрикс ЦРМ.
- Все остальные вакансии без вилок или за 200К разрабатывать на популярном стеке
И условный Васян посмотрит, почешет репу, и пойдёт изучать Митрикс ЦРМ. Через полгода он знает и распространяет эту технологию.
При этом, такие компании могут даже не хотеть новых разрабов и будут заваливать их на собесах, мывамперезванивать и в фоне набирать список достойных кандидатов на всякий случай.
А так да, статья нормальная, буду практиковать. Опоздание на 5 минут -- нормальная штука, как и растяигвание митингов свыше запланированного времени (от того и возникают опоздания на следующий митинг)
Я бы также рекомендовал проверять знания в ширину на стыке стеков.
Например, бэкендер обязательно должен знать минимум две технологии фронтента, чтобы разговаривать с фронтенд-разработчиками на общем языке.
Точно также фронтендер должен знать бэк.
Нафига нужен фронтендер, который не знает базы данных и всё с ними связанное? Ему от туда, между прочим, на фронт данные льются!
Должен знать PHP и его туллинг, чтобы понимать, на что рассчитвать со стороны бэка. И на случай, если надо что-то там подфиксить, пока пехапешник перекрашивает кнопку по другой задаче.
Можно, кстати, попробовать заменить
$headerLine = socket_read($this->acceptedSocket, 1);на использованиеsocket_recv()и забенчить снова.Сдаётся мне, на этом можно здорово сэкономить
Под многие вещи у amphp есть асинхронные драйвера. Можно сразу туда идти и набирать. Или сразу на AMP писать :)
Однако вендорные штуки или ORM переписывать всё-равно не будешь
¯\_(ツ)_/¯. А там и PDO, и чего только нет.Ещё одна большая проблема — протекание контекста. Например один общий Unit of Work или Entity Manager. В некоторых случаях даже разные инстансы контейнера на отдельный запрос не помогут.
Можно поизучать репозиторий https://github.com/buggregator/trap/
Реализованы в какой-то мере HTTP, WebSocket, SMTP.
Я бы, конечно, не рекомендовал на PHP писать серверы прям на замену RoadRunner, FPM и т.д., как минимум потому что:
всегда что-то будет работать в блокирующем режиме (работа с файловой системой, STDIN/OUT, PDO или вендорный пакет)
пыховский zval всегда будет тормознее примитивов в C/Go/Rust...
Но погружаться в эту тему всё-равно как-то надо. Для лёгкого старта можно попробовать phasync, который поможет юзать файберы в ограниченном контексте на готовом проекте. Останется только найти, что параллелить :) говорят под доктрину есть async драйвера
...->findOne() ?? throw new NotFoundException();
¯\_(ツ)_/¯Вспомнилась статья, в которой чувак рекомендует всегда использовать
firstOrFail(). А когда надо выкинуть своё исключение, то он оборачивает вtry/catch. Причём в его кейсе даже без$previous.Что же они там три раза переписывали?
Мне хватило 1 раз переписать Cycle, чтобы композитные PK добавить :D
Быстрая разработка на Laravel подразумевает, что человек знает все эти фасады и сокращения. Поэтому, сдаётся мне, вчерашние студенты одинаково медленно и отвратительно решат задачу на любом фреймворке :)
И выиграет в итоге тот, у которого будет Copilot.
@butschster Использование любого профилировщика на проде будет не бесплатно, в т.ч. Blackfire
Первая ссылка в поисковике: https://github.com/ahocquard/blackfire-overhead-costs
@CodeMaster125 может у вас какой-то более конкретный вопрос по дебажинью продакшена? Если проблема на конкретном сервере, то, наверное, дело уже не в коде и профайлер тут не поможет?
Математические функции я бы вообще не трогал, но если доводить до абсурда, то можно сделать билдер или флюентный интерфейс.
Если бы функция была чуть более высокой абстракции, то передача данных ДТОшкой могла бы быть уместной.
Интроспекция есть в любом зрелом dbal.
Переход на protobuf не решит вашу проблему?
В сигнатуре InputDto и ResultDto. Контракты в proto-файлах.
Этот недостаток можно попробовать решить интерцепторами. Тут сложность возникнет с тем, чтобы описать их на всех языках, на которых написаны Workflow. Но если у вас только PHP, то аля deptrac|nocolor на интерцепторах - интересный вызов :) Интерцепторы уже можно щупать, установив SDK версии
2.7.0@dev.Примеры некоторых доступны в семплах https://github.com/temporalio/samples-php/pull/40/files
А ещё можно пойти по пути упрощения фабрик Activity/Workflow. Код выглядит так:
TaskQueue и прочие настройки, если постоянные, берутся из атрибутов. Те, что определяются по месту - передаются аргументами.
Есть ли способ без хаков уменьшить гигантскую панель слева (без изменения общего масштаба)?
Сам предпочитаю PHPStorm, т.к. VSCode с любым количеством плагинов не дотягивает до возможностей IDE. Однако скорость работы VSCode (особенно в WSL) иногда подкупает.
В мире PHP, кстати, VSCode вряд ли займёт лидирующую позицию.
Ну, Yii 2 проблем скорее всего не создаст - там давно фичефриз и очень широкий диапазон поддерживаемых версий PHP.
Проблем стоит ждать от сторонних библиотек и, естественно, от кода проекта.
В последнем не редки такие сюрпризы, что аннотации с типами отличаются от фактического типа. Тогда ректорить такой проект надо с чательной ручной модерацией.
Согласен с тем, что лучше обновлять поэтапно. Каждый этап - это `composer up` + `composer why-not php x.x`. Если есть блокеры - разбираться с ними, потом с кодом проекта.
Удачи.
Жаль, что для других фреймворков не подойдёт. </sarcasm>
Не, правда, это же просто инструкция по установке/настройке OpenServer. Причём тут Laravel?
Если всё-таки про быстрый запуск лаки на винде, то почему не рассмотрен Laragon? Мне кажется с ним быстрее будет.