- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Не, он не о том. Персонаж выше скатился в демагогию и намекает, что определить точное (совсем точное) время разрыва соединения не получится, вследствие чего скрипт проработает ещё немного после времени последнего успешно переданного бита информации. Но нахрена об этом вещать - я не просёк.
Это называется снобизм, ну или занудство ☝
Но нахрена об этом вещать - я не просёк.
А вот это, как раз, самое простое - поведение скрипта зависит от настроек веб-сервера. И да - там ни слова демагогии, я старался максимально доходчиво, на пальцах описать реальную ситуацию. Ну, проще уже никак нельзя 😕
А вот это, как раз, самое простое - поведение скрипта зависит от настроек веб-сервера. И да - там ни слова демагогии, я старался максимально доходчиво, на пальцах описать реальную ситуацию. Ну, проще уже никак нельзя
Вы же понимаете, что ТС хочет просто разрешить исполняться сорцу до конца, а не пытается узнать жив ли клиент?
Чтобы скрипт продолжал работать для этого есть функция ignore_user_abort.
На php уже лет 5 не пишу, но думаю что ничего с тех времён не изменилось.
Известно, автор же написал что скрипт выполняется несколько десятков секунд, всё это время сокет весит.
Советнички 😂.
В подписи написано опыт 5 лет, а ответ нормальный дать не можете, вместо этого картинка про работу браузеров уровня 2000х годов.
Упс. Не внимательно прочитал
Вы же понимаете, что ТС хочет просто разрешить исполняться сорцу до конца, а не пытается узнать жив ли клиент?
Да, разумеется. :)
Я также соглашусь, что крутить настройки апача (или что там у топикстартера) под такую задачу - плохой вариант. :)
Возвращаясь к самой задаче (это уже для автора топика), один из разумных методов для медленного post-запроса - это создание очереди в БД, записывать туда параметры запроса, возвращать клиенту "ваше задание поставлено в очередь на обработку", а каким-нибудь скриптом по cron-у разгребать, например раз в минуту, эту очередь.
Да, разумеется. :)
Я также соглашусь, что крутить настройки апача (или что там у топикстартера) под такую задачу - плохой вариант. :)
Возвращаясь к самой задаче (это уже для автора топика), один из разумных методов для медленного post-запроса - это создание очереди в БД, записывать туда параметры запроса, возвращать клиенту "ваше задание поставлено в очередь на обработку", а каким-нибудь скриптом по cron-у разгребать, например раз в минуту, эту очередь.
Ваш вариант ничем не лучше изменения конфигов апаче.
Ваш вариант ничем не лучше изменения конфигов апаче.
Ошибаетесь, уважаемый, этот вариант значительно лучше, я бы сказал - классический (для медленных запросов) 🍿
Да, разумеется. :)
Я также соглашусь, что крутить настройки апача (или что там у топикстартера) под такую задачу - плохой вариант. :)
Возвращаясь к самой задаче (это уже для автора топика), один из разумных методов для медленного post-запроса - это создание очереди в БД, записывать туда параметры запроса, возвращать клиенту "ваше задание поставлено в очередь на обработку", а каким-нибудь скриптом по cron-у разгребать, например раз в минуту, эту очередь.
В 95% или даже 99% крутить ничего не надо, куча скриптов работает по такому принципу, причём не на коленке писанных.
У которых просто указано set_time_limit и ignore_user_abort. А они в свою очередь могут работать хоть по несколько часов.
Хотя сейчас так писать не стоит, если что-то серьёзное пишется.
Интересная тема все таки получилась)
В 95% или даже 99% крутить ничего не надо, куча скриптов работает по такому принципу, причём не на коленке писанных.
У которых просто указано set_time_limit и ignore_user_abort. А они в свою очередь могут работать по несколько часов.
это всё же плохая практика.
клиент может дергать скрипт ежесекундно, выйти за лимиты процессов/потоков.
да и для фонового процесса держать ненужный апач тоже не очень хорошо.