Не надо никаких циклов в обработчике запроса! Пока цикл не завершится, запрашивающий не получит ответ на запрос. А 5 минут никто ответа ждать не будет, тем более что запрос сам оборвётся раньше
Обычно это делают как отправку "задания" на сервер. То есть s1 делает запрос нам на выполнение задачи, в ответ возвращается id задачи. Где-то на сервере в отдельном потоке или даже в отдельном скрипте задача потихоньку пытается выполниться (можно сделать обмен данными, например, через базу). Или через модули типа schedule выполнять регулярную задачу проверки "не нужно ли уже считать запрос неудавшимся". Когда приходит запрос от s2, можно сверить время его выполнения с временем первого запроса и сразу ответить ему и пометить для s1 результат для последующего ответа.
s1 может регулярно делать запросы "а скажи-ка мне статус такой-то задачи". Или можно вернуть s1 результат через callback (наш сервер сам дёрнет s1 и передаст ответ).
В общем, примерно такие методы используются в подобных задачах. А как именно сделать в данном случае - это нужно уже смотреть его особенности.
Dr. Bacon, ssh-туннели работают не настолько надёжно, чтобы через них что-то прям прокидывать. Я лет 5 назад для одной задачи наскоро сваял такой туннель, и вот он иногда просто подвисал и всё... Если бы это было для себя я бы мог его передёргивать каждый раз, но я делал для других людей, и там это было неприемлемо.
@IlyaPook
функции, которые передаются через register_next_step_handler (next) или вызываются из своего собственного кода (hi), не надо оборачивать декоратором message_handler, это ошибка, так как в результате декорирования получается ДРУГАЯ функция, чем описанная (обёрнутая каким-то кодом, который что-то ещё делает).
До кучи, лучше не называть функцию next, так как есть встроенная функция с таким же именем.
Teleweb developer, в былые времена, когда браузеры обладали разным уровнем поддержки js, а сами браузеры ещё не были интерпретаторами скриптовых "приложений", существовала практика имитации выполнения длинных операций следующим образом. Пользователь выполнял действие на сайте, затем его перенаправляло на страницу, где был такой вот refresh и отображалось, что задача ещё выполняется (можно даже проценты рисовать). Как только задача завершалась, очередной запрос показывал, что задача всё и редиректил на другую страницу. Или, например, этот процесс открывался в отдельном окне/фрейме, по завершении задачи предлагалось его закрыть. Или в нём, например, давалась ссылка на файл, который долго подготавливался этим процессом.
Выглядело это не особо красиво, и с появлением ajax, а также всяких long poll и websocket ушло в прошлое. Но механизм остался, пусть его и используют сейчас крайне редко.
Да скорее всего где-нибудь в назначении платежа передаётся логин. Вон, домены у регистраторов доменов тоже можно чисто по имени домена проплачивать, и есть случаи когда люди продлевают домены, зареганные на уже умерших родственников и друзей...
Для подготовки к ЕГЭ - нет, вообще никак. В ЕГЭ нужно решить ограниченный класс задач за отведённое время, для подготовки к ЕГЭ нужна практика решения таких задач, тренировка рук и мозга. Чтобы во время экзамена не уложиться в лимит времени. Поэтому к ЕГЭ лучше всего помогают подготовиться школьные уроки математики и решение задач ЕГЭ прошлых лет.
lolrofl01, dump.sql скорее всего заливается один раз при первой инициализации базы, а не при каждом запуске. Это не сама база, а её бэкап.
При запуске докер создась ./mysql (если его нет) и прокинет в /var/lib/mysql внутри контейнера. Сама база инициализируется, видимо зальёт dump.sql при первом запуске (это предположение, я не изучал как устроен этот контейнер, может он и при каждом запуске заливает дамп?), а затем при следующих запусках/перезапусках/пересозданиях контейнера внутри будет /var/lib/mysql с уже накопленными данными.
Uno, мы первого джуна-сисадмина когда взяли там всё очень тускло было (в том числе по софтскиллам), через неделю его перевели для обучения в третью линию саппорта, и в итоге он не прошёл испытательный срок. После этого следующих джунов уже взяли после того, как забраковали десятки(!) негодных.
Обычно это делают как отправку "задания" на сервер. То есть s1 делает запрос нам на выполнение задачи, в ответ возвращается id задачи. Где-то на сервере в отдельном потоке или даже в отдельном скрипте задача потихоньку пытается выполниться (можно сделать обмен данными, например, через базу). Или через модули типа schedule выполнять регулярную задачу проверки "не нужно ли уже считать запрос неудавшимся". Когда приходит запрос от s2, можно сверить время его выполнения с временем первого запроса и сразу ответить ему и пометить для s1 результат для последующего ответа.
s1 может регулярно делать запросы "а скажи-ка мне статус такой-то задачи". Или можно вернуть s1 результат через callback (наш сервер сам дёрнет s1 и передаст ответ).
В общем, примерно такие методы используются в подобных задачах. А как именно сделать в данном случае - это нужно уже смотреть его особенности.