Comments 28
А они должны ?
Понятно что это "приятный бонус" для работодателя, но серверами разве не должны другие люди заниматься ?
На других языках по другому ?
Каждый питонист знает как настроить rate limit в nginx или отбросить ненужные запросы чтобы они даже до приложения не доходили ?
-- ADDED ибо косякопор (лимит на сообщения)
Я понял о чем речь. Видимо про это https://habr.com/ru/articles/179399/
В мозгах ПХП разработчика нет таких проблем как неочищенная память, статические переменные между запросами и т.п.
Есть запрос, твой скрипт должен вернуть ответ - ВСЕ.
Каждый запрос "новая жизнь".
Очень удобно, но не всегда, как вы заметили. Так и живем )
А они должны ?
Web-сервер является неотъемлемой частью при разработке web-приложений.
Зная основы работы можно оптимизировать код, чтобы расходов на серверы было меньше.
Понятно что это "приятный бонус" для работодателя, но серверами разве не должны другие люди заниматься ?
Данная статья не про настройку web-сервера, а про основные моменты, которые разработчик должен понимать.
На других языках по другому ?
Да, в других языках нет прямой зависимости 1 worker = 1 запрос
Каждый питонист знает как настроить rate limit в nginx или отбросить ненужные запросы чтобы они даже до приложения не доходили ?
Rate-limit это уже настройка от перегрузки запросами, зная особенности работы web-сервера на PHP можно ускорить обработку запросов, например, вынеся часть операций в фоновую обработку.
Зная основы работы можно оптимизировать код, чтобы расходов на серверы было меньше
Желательно чтобы хотя бы один человек на проекте это знал. Хотя если запросов мало, то пофиг на оптимизации.
если эти основы знает только один человек на проекте, а разработчиков несколько, то получается неудобно: практически все решения должны проходить через этого человека; он становится "бутылочным горлышком". Проще дать людям 10 минут прочитать эту статью, чтобы они сами отсеивали самую лютую дичь из своих решений.
Web-сервер является неотъемлемой частью при разработке web-приложений.
Процессор тоже является неотъемлемой частью при разработке любых приложений. Вы хорошо ассемблер знаете? Можете написать программу перехода из реального в защищенный режим? Провести отладку с GDB или IDA?
Да, в других языках нет прямой зависимости 1 worker = 1 запрос
В php, благодаря растущей популярности RoadRunner, тоже уже нет такой зависимости.
зная особенности работы web-сервера на PHP можно ускорить обработку запросов, например, вынеся часть операций в фоновую обработку.
Фоновая обработка с веб-сервером не связана почти никак.
Или вы что-то меняли в коде очередей при переезде с апача на nginx?
А если вы про fastcgi_finish_request, то это не совсем "фоновая обработка", сервер в целом от этого не ускорится.
Да, пжлст больше вариантов использования накидайте и свои наблюдения от использования (они самые ценные). Нам тут есть куда применить. Спасибо!
Разработчики на PHP умеют писать код, но не всегда знают как устроен web-server
ИМХО, с 2010+ года, разработчики php умеют писать говнокод, и совсем не знают как устроен веб-сервер, не умеют его настраивать и более того, не могут выдать внятные системные требования к веб-серверу, версии php, необходимым библиотекам и т.д., для работы того, что они наговнокодили.
Невозможно подстраивать под себя окружение и не уметь его настраивать. Но большинству не нужно это, ведь буквально всё в вебе делается для облегчения работы
Ну по мне делами сервера должен админ заниматься. Если вы берете к примеру виртуальный хостинг, то там все уже настроено по максимуму изначально.
Кодер на PHP должен знать следующее:
Если у вас 2 и более запроса к базе данных, по одному вопросу, то нужно просто взять руководства по SQL. В большинстве случаев можно все к одному запросу к базе свести.
Если у вас большая работа с данными идет на странице, к примеру графики строятся, таблицы, рисунки, то если данные не секретные передайте их в браузер клиента, и пусть уже там JS мучается с этим вопросом.
никак не решают проблемы с синхронным выполнением запросов во внешние системы, а 90% кода как раз состоит из того, чтобы получить данные из stateful системы, преобразовать и выдать результат и/или передать дальше в stateful систему.
Подскажите, пожалуйста, ваш типичный 90% кодовый случай - что именно и откуда вы берете из внешних систем, как вам тут поможет "асинхронщина для хайлоада" и в чем у вас вообще проблема с асинхронными вызовами в пхп? (ну понятно, что у вас проблем нет, свуля и все такое, но была же в "обычном" пхп)
текст вообще ни о чем, и похож на поток сознания. Смесь всем известной информации из документации и личных домыслов. И выводы просто замечательные (facepalm)
смешались в кучу кони, люди...
У меня вопрос. А как асинхронный код поможет в плане уменьшения ожидания от сторонних систем?
Ну наверное имелись ввиду всё же неблокирующие запросы. Так то, крайне редко, но можно распараллелить какие-нибудь пару запросов на релейшены или два+ независимых запроса чтоб они друг в друга не упирались. Получим целых 20мс выгоды! Ну или сколько там where in по праймари может выполняться...
ну если где-то есть такие неблокирующие запросы, то скорее всего там уже знают что такое асинхронщина и как ее готовить :) Это же изначально совсем другое апи (даже если тот же mysqli юзать в асинк режиме)
Но все-таки судя по описанию и примерам имелись именно обычные такие синхронные запросы ;)
блин, а мужики то не знают что php в high-load не работает, так и пилят свои приложения для сотен миллионов пользователей в день.
пойду сообщу что ли. что не должно это работать, так на хабре написали.
С одной стороны понятен смысл данного поста. Прорекламировать асинхронную разработку под PHP.
Но сделано уж очень непрофессионально (опенсервер для профессиональной разработки - шта?), без указания кучи минусов, которые приносит асинхронщина в PHP.
мы заняли воркер на 3 секунды
никак не решают проблемы с синхронным выполнением запросов во внешние системы
А их обычно и не надо решать. Просто воркеров должно быть больше, чем число запросов, приходящих за эти 3 секунды. Чем длиннее конвейер, тем шире он должен быть.
Асинхронное выполнение имеет смысл, когда есть запросы, которые можно выполнять параллельно, это случается не так уж часто. Если вам надо сначала сохранить заказ, а потом отправить его в стороннюю систему, то асинхронные запросы ничего не изменят.
Пример кода выложил на github
В результате теста у меня получилось
sleep(3);
echo 'Hello world';
Угу, хороший тест. Написали 3 секунды ожидания, получили 3 секунды ожидания.
Получилось предисловие к статье про асинхронность в PHP. Жду основной материал)
Спасибо. Мне, как разработчику с небольшим опытом, интересно было почитать. Есть несколько ошибок в тексте, которые усложняют чтение, восприятие
Для снижения накладных расходов самого web-сервера на обработку запроса они изначально, согласно конфигурации, поднимают
кто "они"?
Для более качественной работы важно для каждого внешнего соединения указывать timeout самого соединения и timeout ответа на запрос. Для защиты от этого в PHP есть специальные настройки
для защиты от чего?
Разработчики на PHP умеют писать код, но не всегда знают как устроен web-server