Почему зависает сайт при 30-40 одновременно выполняемых запросах?

Question

[Us59]

Есть скрипт, посылаю запросы через multi curl к сайту, в ответ, когда запросы выполнены он присылает call back. (каждый запрос он присылает отдельно, по одному ответу).

Когда происходит ситуация, что приходит 30-35 call backов одновременно скрипт запускается, делает обращение к базе, и через proxy начинает выполнять curl запрос, естественно он может висеть долго, т.к. делается через proxy.

Я слышал про система очередей, но не совсем понимаю как это работает и поможет ли в моей ситуации.

Если эта самая система очередей просто откладывает выполнение запросов пока не выполняться предыдущие запросы, то боюсь это не подойдет мне, т.к. срок жизни того, что дает мне сайт через call back всего 2 минуты и я как можно скорее должен сделать запрос.

=====
Когда выполняются много call backов (они запускают curl запросы) при попытке обратится к phpmyadmin страница грузится минутами..., однако через filezila все работает быстро итд.
Ниже показываю как выглядит нагрузка:


Вопрос в итоге такой: Можно ли что-то сделать, или только не нагружать большим количество запросов пока не выполнились старые? Не хватает ресурсов или чего? Поможет ли в моем случае система очередей?

Comments

[Александр Кубинцев]

Есть скрипт, посылаю запросы через multi curl к сайту, в ответ, когда запросы выполнены он присылает call back. (каждый запрос он присылает отдельно, по одному ответу).

Сайт сторонний? Колбеки куда шлёт, на ваш сервер? 1 запрос - 1 колбек?

Когда происходит ситуация, что приходит 30-35 call backов одновременно скрипт запускается, делает обращение к базе, и через proxy начинает выполнять curl запрос, естественно он может висеть долго, т.к. делается через proxy.

Не понял. Как только у вас накопилось 30-35 колбеков вы выполняете (multi-)curl из прошлого абзаца? Речь идёт о задаче по расписанию (cron), которая выполняет очередь заданий из базы данных?

[Us59]

Александр Кубинцев, есть пачка заказов, например 100 штук. В файле start.php я создал ф-цию (multi curl) которая получает заказы из БД и эту пачку передает в Multi curl, который в свою очередь делает запросы к сайту и дает ему "заказы". Проходит некоторое время (2-3 минуты) и сайт начинает присылать выполненные заказы мне обратно, но присылает не пачкой, а по одному. 1 заказ = 1 post запрос к моему серверу, отсюда я не могу сделать multi curl и мне приходится создавать файл callback.php в котором есть ф-ция принятия Post запроса и я вынужден делать Обычный curl запрос к определенному url с результатами которые присылает нам сайт (решение капч).

Исходя из этого всего, когда одновременно обрабатываются много запросов 20-30 сервер просто зависает (точнее, через filezila я могу обращаться и все ок, но если я захочу зайти в phpmyadmin - то я не получу ответ, либо он будет грузить его 2-3 часа наверное)

Почему так происходит? обычный curl делается через proxy и конечно это медленно, но почему виснет сервер-то? я ж не даю ему тысячу одновременно? 20-30 я считаю немного. Может быть какие-то настройки я сделал не правильно? Буду рад любому совету.

Answer 1

[Александр Кубинцев]

Из всего что я понял, получается у вас в callback-хендлере делается запрос через curl куда-то ещё (через proxy) и тем самым воркер из пула web-сервера держится до момента окончания выполнения запроса. Ваш сервачок быстро исчепает пул веб-воркеров, даже если вы увеличите их до 100 и хватит памяти. Конечно, это плохое решение.
Да, в сущности нужно реализовывать систему очередей.
Вам нужно как можно быстрее выполнять пришедний запрос-колбек и освобождать пул. Для этого нужно ограничить его работу тем, чтобы положить необходимые данные в какое-то хранилище или передать сообщением в менеджере очередей, делегировав работу по отправке другому пулу воркеров. Например 1-4 воркерам/демонам на ReactPHP или Node.js, которые будут брать пачку заданий и асинхронно рассылать запросы.

Comments

[Us59]

Александр Кубинцев скажите пожалуйста, как можно в данном случае поступить, если токен, который я получаю от сайта по решению капч действителен только 120 секунд? Если я настрою систему очередей - это никак не поможет насколько я понимаю в таком случае? Просто в теории, получается придет мне call back и я поставлю его в очередь, хотя мне наоборот нужно как можно скорее отправить запрос, чтобы не получить wrong reply

[Александр Кубинцев]

120 секунд вам хватит выше крыши. Если есть возможность сделать очередь через RabbitMQ или Gearman накладные расходы на делегирование будут меньше секунды.
Вам следует больше волноваться о том, как написать воркер для обработки очереди.

[Us59]

Александр Кубинцев, 120 секунд хватит ? Вы учли, то проксики через которые делаю запрос - дохленькие и бывает не рабочие, таймауты ставлю 20 секунд на коннект)
Я представляю эту картину так:
Получил call back, он становится в очередь, очередь освобождается тогда, когда есть свободное место, а место освободится тогда, когда завершатся старые запросы, а поскольку проксики дохленькие - старые запросы будут висеть ох как долго)

[Александр Кубинцев]

Us59, сколько по вашему один воркер сможет взять запросов в работу?

[Us59]

Александр Кубинцев, честно - я мало в этом понимаю, поэтому не могу сказать. Мне наверное просто нужен совет экспертов кто был в подобных ситуациях и знает что можно сделать чтобы работало без зависаний)

[Александр Кубинцев]

Us59, ок, даю подсказку, по меньшей мере 1000 можно.
https://github.com/php-api-clients/rabbitmq-manage...
https://sergeyzhuk.me/2017/07/26/reactphp-http-client/

[Us59]

Александр Кубинцев, Хорошо, подведем итоги: Мне нужно использовать очередь запросов через RabbitMQ или Gearman и таким образом я буду избегать зависаний которые испытывает сервер сейчас при 20-30 одновременно вызванных call backах, поскольку будет использоваться очередь.

Сразу возникают вопросы: Получается, RabbitMQ просто ставит запросы в очередь в формате:

1
2
3
4

Когда сервер выполнил какую-то задачу - сразу ставится новая из очереди.

Получается, это просто ограничение принятия количества запросов для обработки, таким образом, возможно мне проще делать меньшее количество запросов к сайту, который присылает call backи, допустим могу сделать ограничение 10 запросов, как только они выполнились - статус изменился и можно загружать еще 10 итд - этот вариант намного проще)

Для меня кажется странным, что сервер виснет при 20-30 одновременно выполняемых curlах, разве нет?((

[Александр Кубинцев]

Us59, вы никак не поймете что происходит. Веб-сервер у вас имеет порядка 30 воркеров. Один воркер работает одновременно над одним запущенным php-скриптом. В рамках нынешнего вашего воркера получается приём данных запроса от стороннего сервера (колбек) и в нём же, не завершая, вы делаете новый запрос, который долго ждёт какого-либо ответа от 3-го сервиса.
Когда быстро приходит 30-35 колбеков у вас весь пул/очередь из воркеров исчерпывается, т.к. освобождаются они медленно из-за медленных запросов.
Поэтому еще 1 воркер, который отрабатывает вам phpmyadmin выделяется с задержкой (после отработанного скрипта по колбеку). Хуже всего в данной ситуации не это, а то, что вы не можете в этот момент принимать новые колбеки, где как раз и теряете отведенные вам 120 секунд. А вы наверное и не догадывались об этом?

Создавая очередь у вас будет хороший запас по отказоустойчивости, т.к. веб-воркеры будут завершаться в разы быстрее. Можете конечно пойти другим путем: сделать например 200 веб-воркеров и надеяться, чтобы этот пул себя не исчерпал. Но я не уверен, что вам хватит ресурсов сервера. Если есть возможность ограничить кол-во колбеков - тоже сделайте. Но я не знаю насколько вам это решение подойдет, думаю оно так себе.

[Us59]

Александр Кубинцев, Александр Кубинцев, остается 1 вопрос - почему воркеры будут освобождаться быстрее?

proxy начнут быстрее работать или что?)
У меня есть 1 файл где я делаю и прием и запрос на 3-й сервис, принял калл бэк - сразу делаю запрос, а что в этом плохого? Нужно сначала записать ответ кэлл бека и потом ставить очередь ?) так чтоли?) а где оно быстрее будет всеравно 1 воркер - 1 обработка. Или я что-то не понимаю? :(

Тут воркеры заканчиваются из-за того, что много curl запущено одновременно, и они все через proxy висят долго, а от того, что я создам очередь - не понимаю из-за чего лучше должно стать, конечно если очередь будет - не будет зависаний, но по факту обработать большее количество я не смогу, верно? Тогда зачем городить мне эту эпопею с очередью тратить время на изучение и изменения кода, если можно просто задать ограничение на отправку запросов, чтобы приходило меньше call backов и получится практически тоже самое, разве нет?) Тут наверное нужно думать, как одновременно выполнять 50-100 curl запросов одновременно, без очереди.

[Александр Кубинцев]

Us59,

почему воркеры будут освобождаться быстрее?

Потому что ВЕБ-воркер будет только заниматься приёмом колбека и передачей его в очередь.
Попробую изобразить таймлайн.

ВЕБ-ВОРКЕР С ОЧЕРЕДЬЮ
|======= 5мсек ========|==== 1 мсек======|======>
| Приём колбек-запроса | Запись в очередь | Конец

ВЕБ-ВОРКЕР БЛОКИРУЮЩИЙ (ТЕКУЩИЙ)
|======= 5мсек ========|==== 15000 мсек=======================|======>
| Приём колбек-запроса | Проксирование запроса             | Конец

Да, запрос через прокси надо исполнить. Но его исполнять будет ДРУГОЙ процесс или процессы, которые никак не связаны с веб-сервером. Таким образом веб-воркер будет освобождаться раньше и сможет принять больше колбеков, вместо 502-й ошибки.

Теперь что касается исполнения запросов через прокси. Я выше написал две ссылки, по которым можно написать простенький пхп-демон на ReactPHP, который будет асинхронно выполнять ТЫСЯЧИ запросов через прокси. Потому что в нём операции эти неблокирующие и CPU практически не съедают (только память потребуется).
Таким образом пул веб-воркеров будут практически всегда свободен, а запросы через прокси будут параллельно выполняться другим процессом.

[Us59]

Александр Кубинцев, спасибо буду пробовать.

[Александр Кубинцев]

Us59, пожалуйста. Как вариант можно вообще научить демона принимать и колбеки, и слать запросы. Но на мой взгляд это менее надёжно. В конце концов можно даже посадить демона на другой сервер.

Answer 2

[Wexter]

1) Если PHP работает через FPM - увеличить количество процессов покуда хватает памяти/процессора
2) Если работает через апач - выкинуть апач и поставить FPM, затем повторить п. 1
3) Если уж хотите очереди - скармливайте запросы серверу очередей, клиенту отдавайте ID задачи, а клиент раз в N секунд пусть опрашивает завершилась задача или нет

Comments

[Us59]

памяти как я понимаю используется 79% т.е. уже и так много.

Система очередей просто получит задачу и будет выполнять ее когда освобождается свободное место или что? У меня время жизни результата который вернул call back - 2 минуты, тут очередь нельзя ставить...

[Wexter]

Us59, очередь будет получать задачу и отдавать воркерам когда те освобождаются, количество воркеров подгоняете под нужную нагрузку/скорость обработки. Тут уж сами решайте что вам важнее, время обработки и зависший сервер или свободный сервер но большее время обработки

[Everything_is_not_so_bad]

Wexter, как правило, апачи ни при чём.

[Wexter]

Роман Мирр, как правило апач жрёт ресурсов как не в себя и плохо параллелится

[Everything_is_not_so_bad]

Wexter, это зависит от того как настроен и используется.

Answer 3

[Алексей Сундуков]

Для общего понимания происходящего: Сколько выдержит мой сервер?

Answer 4

[Everything_is_not_so_bad]

Скорее всего из-за выполнения блокирующих операций I/O.

Comments

[Us59]

Можно подробнее? что за i/o?

[Everything_is_not_so_bad]

Us59, операции с получением/отправлением данных по сети, диска или СУБД.

[Everything_is_not_so_bad]

Us59, https://tproger.ru/translations/diversity-of-input...