Простите, но исследование просто рисует те цифры, которые захотелось нарисовать.
Статья называется "зарплаты IT-управленцев", но география исследования достаточно узкая. В ней архитектор может и получает больше, чем CIO. Но давайте говорить по-честному - распределение доходов в РФ по гео не носит характер гауссовского.
Отсюда мы получаем, что название статьи не очень-то соответствует содержанию.
Также в статистике из 2500 респондентов совершенно непонятно, сколько было опрошено тимлидов, а сколько - директоров.
Нисколько не отрицаю, что архитекторы и лиды важны. Но вот достоверность результатов исследования вызывает вопросы.
Разумеется, это часть уже непосредственно всей архитектуры, а не отдельно взятого слоя.
Если говорить про Laravel в целом, то там вроде в LazyCollections еще генераторы используются. И если верить бенчмаркам, то кажется, что даже эффективненько.
Кто-то будет искать информацию, связанную с проблемой полного выжирания памяти на стороне БД огромным запросом. Но сделав один шаг, скорее рано, чем поздно упрётся во вторую проблему, о которой я и написал в комментарии выше.
А, судя по моим наблюдениям, несмотря на уже существенный срок существования, генераторы встречаются довольно редко. Хотя, тут могу ошибаться.
Впрочем, тут, конечно же, надо понимать, что все подряд в одной статье не покроешь. Тем более, это же статья на основе выступления, которое к тому же довольно жестко ограничено по времени.
Классная статья! Спасибо! Видно, что проделана большая работа.
Мы переехали на mysqlnd — изменился режим работы с буферизированными запросами. Сделали большой запрос — и это при получении может вызвать переполнение памяти. Выключите и получайте большие объёмы данных из соединения постепенно.
Вот тут было бы интересно уточнить о методах получения данных постепенно. Дело в том, что переполнение в таком случае можно продолжать схватывать, если на выходе при переборе обычным циклом собирать все данный в какой-нибудь выходной массив, передаваемый дальше.
Обрабатывать данные на месте, если уж строится инфраструктурный слой приложения, некруто. Поэтому их как-то надо отдавать на уровень бизнес-логики в обработчики. И тут на помощь могут прийти правильно приготовленные генераторы. "Правильно приготовленные" я тут понимаю так, что нигде в приложении при работе с небуферизованными запросами в БД не надо пытаться складывать весь пакет данных - его надо сразу обрабатывать, получать консолидированный результат и забывать.
В целом, ответ на вопрос есть в комментарии @acordell
Если запросов не очень большое количество, то и выигрыш призрачен. Но вот если говорить о большом объёме инстансов, то уйма ресурсов будет уходить на инициализацию соединения. То есть, мы не запускаем, скажем 100 инстансов, в каждом из которых пилим N потоков через Singleton - ситуация тут, когда, скажем, через fastCGI в Python летит 100*N запросов на получение данных.
Поддержу. Ведь тот же тест через Singleton может быть нерелевантен, если приложение запускается в несколько инстансов. И тогда пул коннектов, который можно шарить между процессами, становится прямо таки важным аспектом реализации.
Спасибо за статью! Понимаю, что она сосредоточена именно на применении механизма очередей, но вот история с тем, что от монолита отпиливается по одному handler-y, имеет риск с другой стороны.
Кажется, что здесь важно иметь четкое архитектурное правило последующего размещения этих ручек по сервисам. Ведь это будет долгий процесс. И за время работы над ним может не просто что-то забыться - команда может поменяться. И как бы не получилось так, что ручки в итоге начнут переноситься по сервисам не особенно корректно. Как следствие, микросервисы превратятся в Service Mess, если можно так выразиться.
Поэтому упускать этот аспект, говоря о распиле монолитов, кажется рискованным.
Относительно утечек памяти в генераторах вот, что сумел накопать
https://github.com/php/php-src/issues/9750 - в случае, если цикл, обращающийся к генерируемым результатам останавливается через break, то случается утечка. Но это уже пофиксили. Судя по всему, это даже в 8.0 влили.
Более древние упоминания (типа 5.х) я тут не рассматривал, так как там и без утечек хватает проблем :)
В целом, генератор уничтожается в памяти в момент, когда либо доходит до конца своих условий работы, либо на него заканчиваются ссылки. Что, собственно, логично в контексте Zend Engine.
Да, тут зависит от решаемой задачи. Контейнеры тут будут выполнять задачу изоляции процессов и стандартизации сред исполнения. Конечно, если надо прям вот упаковать и доставить без доступа к хосту, то volume не прокатит.
Это надо с нуля учить выносить в .env, иначе вся сборка становится абсолютно непортируемой между средами разработки.
Относительно Pgadmin: все таки админские интерфейсы для БД - ну такое. Ведь всегда можно подключиться нативным клиентом, который проще завернуть во внутреннюю сетку.
Не уверен, что контейнер node собирается оптимально. Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код. Точно нельзя это упаковать в один шаг копирования?
Спасибо! В принципе, не большой секрет, что эта статья основана на моем выступлении на конференции PHP Russia 2022. И когда я готовился, надо было все упаковать в достаточно сжатые временные рамки. Но конечно же, я при подготовке рассматривал и reactPHP. Но вот все упихать в 37 минут рассказа нереально :)
Без проблем) Я заодно решил сам себя перепроверить в тексте, так как с утверждением о разнице полностью согласен.
Да, тег тут огульно поставлен, поправлю. В статье вроде бы знака равенства я не указывал :)
Простите, но исследование просто рисует те цифры, которые захотелось нарисовать.
Статья называется "зарплаты IT-управленцев", но география исследования достаточно узкая. В ней архитектор может и получает больше, чем CIO. Но давайте говорить по-честному - распределение доходов в РФ по гео не носит характер гауссовского.
Отсюда мы получаем, что название статьи не очень-то соответствует содержанию.
Также в статистике из 2500 респондентов совершенно непонятно, сколько было опрошено тимлидов, а сколько - директоров.
Нисколько не отрицаю, что архитекторы и лиды важны. Но вот достоверность результатов исследования вызывает вопросы.
Разумеется, это часть уже непосредственно всей архитектуры, а не отдельно взятого слоя.
Если говорить про Laravel в целом, то там вроде в LazyCollections еще генераторы используются. И если верить бенчмаркам, то кажется, что даже эффективненько.
Тут еще вопрос подачи информации же :)
Кто-то будет искать информацию, связанную с проблемой полного выжирания памяти на стороне БД огромным запросом. Но сделав один шаг, скорее рано, чем поздно упрётся во вторую проблему, о которой я и написал в комментарии выше.
А, судя по моим наблюдениям, несмотря на уже существенный срок существования, генераторы встречаются довольно редко. Хотя, тут могу ошибаться.
Впрочем, тут, конечно же, надо понимать, что все подряд в одной статье не покроешь. Тем более, это же статья на основе выступления, которое к тому же довольно жестко ограничено по времени.
Классная статья! Спасибо! Видно, что проделана большая работа.
Вот тут было бы интересно уточнить о методах получения данных постепенно. Дело в том, что переполнение в таком случае можно продолжать схватывать, если на выходе при переборе обычным циклом собирать все данный в какой-нибудь выходной массив, передаваемый дальше.
Обрабатывать данные на месте, если уж строится инфраструктурный слой приложения, некруто. Поэтому их как-то надо отдавать на уровень бизнес-логики в обработчики. И тут на помощь могут прийти правильно приготовленные генераторы. "Правильно приготовленные" я тут понимаю так, что нигде в приложении при работе с небуферизованными запросами в БД не надо пытаться складывать весь пакет данных - его надо сразу обрабатывать, получать консолидированный результат и забывать.
В целом, ответ на вопрос есть в комментарии @acordell
Если запросов не очень большое количество, то и выигрыш призрачен. Но вот если говорить о большом объёме инстансов, то уйма ресурсов будет уходить на инициализацию соединения. То есть, мы не запускаем, скажем 100 инстансов, в каждом из которых пилим N потоков через Singleton - ситуация тут, когда, скажем, через fastCGI в Python летит 100*N запросов на получение данных.
Поддержу. Ведь тот же тест через Singleton может быть нерелевантен, если приложение запускается в несколько инстансов. И тогда пул коннектов, который можно шарить между процессами, становится прямо таки важным аспектом реализации.
Спасибо за статью! Понимаю, что она сосредоточена именно на применении механизма очередей, но вот история с тем, что от монолита отпиливается по одному handler-y, имеет риск с другой стороны.
Кажется, что здесь важно иметь четкое архитектурное правило последующего размещения этих ручек по сервисам. Ведь это будет долгий процесс. И за время работы над ним может не просто что-то забыться - команда может поменяться. И как бы не получилось так, что ручки в итоге начнут переноситься по сервисам не особенно корректно. Как следствие, микросервисы превратятся в Service Mess, если можно так выразиться.
Поэтому упускать этот аспект, говоря о распиле монолитов, кажется рискованным.
Относительно утечек памяти в генераторах вот, что сумел накопать
https://github.com/php/php-src/issues/9750 - в случае, если цикл, обращающийся к генерируемым результатам останавливается через break, то случается утечка. Но это уже пофиксили. Судя по всему, это даже в 8.0 влили.
Более древние упоминания (типа 5.х) я тут не рассматривал, так как там и без утечек хватает проблем :)
В целом, генератор уничтожается в памяти в момент, когда либо доходит до конца своих условий работы, либо на него заканчиваются ссылки. Что, собственно, логично в контексте Zend Engine.
Да, тут зависит от решаемой задачи. Контейнеры тут будут выполнять задачу изоляции процессов и стандартизации сред исполнения. Конечно, если надо прям вот упаковать и доставить без доступа к хосту, то volume не прокатит.
Спасибо! Но в таком случае не проще исходники вольюмом пробросить?
Хорошо! Но вот что тут стоит поправить с точки зрения контейнеров
хранение кредов.
Это надо с нуля учить выносить в .env, иначе вся сборка становится абсолютно непортируемой между средами разработки.
Относительно Pgadmin: все таки админские интерфейсы для БД - ну такое. Ведь всегда можно подключиться нативным клиентом, который проще завернуть во внутреннюю сетку.
Не уверен, что контейнер node собирается оптимально. Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код. Точно нельзя это упаковать в один шаг копирования?
Да, конечно. Посмотреть можно здесь https://youtu.be/EZi8dML6UAQ
Да, вот только добрался посмотреть - совсем не про то. Хочется увидеть материалы именно относительно утечек в генераторах.
Спасибо, почитаю!
Спасибо! В принципе, не большой секрет, что эта статья основана на моем выступлении на конференции PHP Russia 2022. И когда я готовился, надо было все упаковать в достаточно сжатые временные рамки. Но конечно же, я при подготовке рассматривал и reactPHP. Но вот все упихать в 37 минут рассказа нереально :)
Спасибо! Кстати, а есть что почитать про утечки в генераторах?
Разумеется. Спасибо за дополнение. Я тут, скорее, хотел показать, что и силами PHP можно решить эту задачу.
Я в тот момент остановился после первого "нереально щедрого предложения", так как хрен в башке стал очевиден невооруженным глазом.