Комментарии 34
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Таймаут соединения можно решить например через постоянные подключения.
0
Покажите где такое есть в PDO?
0
<?php
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass, array(
PDO::ATTR_PERSISTENT => true
));
?>
php.net/manual/en/pdo.connections.php
0
Читайте внимательно
Постоянные соединения не закрываются при завершении работы скрипта, они кэшируются и используются повторно, когда другой скрипт запрашивает соединение с теми же учетными данными
К сожалению этот параметр не решает проблему сброса соединения со стороны MySQL сервера.
Постоянные соединения не закрываются при завершении работы скрипта, они кэшируются и используются повторно, когда другой скрипт запрашивает соединение с теми же учетными данными
К сожалению этот параметр не решает проблему сброса соединения со стороны MySQL сервера.
+1
Мое дело малое, показать как сделать в PDO персистентное соединение. А по поводу проблемы с таймаутами — не вижу проблемы как таковой. По умолчанию у mysql этот таймаут равен 8-ми часам если память не изменяет. С другой стороны я не вижу смысла какому-либо скрипту держать соединение с базой дольше чем минуту. Если у вас возникают проблемы с таймаутами — то скорее всего у вас просто что-то не так с реализацией задачи. Если нужно что-то долго обсчитывать в базе — открываем соединение — достаем данные — закрываем. Оно нам не понадобится пока не обсчитаем все. Можно сделать очередь задачи и все такое прочее.
-1
Персистентные соединения вообще ничего связанного с таймаутами, отличное от обычных, неперсистентных соединений, не имеет.
Персистентные соединения это лишь пул, который, в случае с кроновскими и шелл-скриптами вообще некому будет создать и поддерживать.
Персистентные соединения это лишь пул, который, в случае с кроновскими и шелл-скриптами вообще некому будет создать и поддерживать.
+1
Я вел речь о запланированно долгих скриптах, а не о плохооптимизированных
Долгие операции нужно выносить за пределы, и выполнять их, например, в кроне.вообще-то, в конце я написал о том, что долгие операции следует выполнять в фоновом режиме (в кроне это делать или запускать в качестве фонового процесса — зависит от задачи и особого значения не имеет)
0
3 Видео Урока Евгения Попова… используя готовые скрипты на PHP с сайта woweb.ru :)
+2
В mysql может быть полезно установить таймауты больше, если предполагается что обработка займет продолжительное время.
SET SESSION wait_timeout (ну и interactive_timeout тоже) = 9999
+2
да, но не всегда есть возможность менять параметры MySQL
0
To indicate explicitly that a variable is a session variable, precede its name by SESSION, @@session., or @@. Setting a session variable requires no special privilege, but a client can change only its own session variables, not those of any other client.
dev.mysql.com/doc/refman/5.0/en/using-system-variables.html
+5
НЛО прилетело и опубликовало эту надпись здесь
добавил
0
Тогда уж добавляйте, интересный для меня, пример к
И опишите «нюанс» с mysql_reconnect (этим я уже не пользуюсь, как и mysqli_*) когда он переподключается с параметрами «по умолчанию», а не с теми параметрами, с которыми он подключался.
При необходимости можно периодически проверять состояние обработки при помощи AJAX запросов.
И опишите «нюанс» с mysql_reconnect (этим я уже не пользуюсь, как и mysqli_*) когда он переподключается с параметрами «по умолчанию», а не с теми параметрами, с которыми он подключался.
0
Не хватает примера запуска скрипта через php-cli из кода.
0
для nginx send_timeout и fastcgi_read_timeout (если PHP работает через FastCGI)Потрудитесь объяснить причем тут вообще send_timeout.
Если скрипт запускается в ответ на HTTP-запрос, то пользователь может остановить выполнение запроса в своем браузере, в этом случае прекратит свою работу и PHP скрипт.Это, мягко говоря, не всегда так.
0
А не лучше сделать выполнения клиентской части на клиентской машине? В наше время уже давно используется Ajax…
0
Потрудитесь объяснить причем тут вообще send_timeout.
Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями записями. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.
На сколько я понимаю, если скрипт отправит что-то клиенту, после чего долгое время (больше чем указано в send_timeout) будет «молчать», то соединение закроется. Поправьте если я ошибаюсь
Это, мягко говоря, не всегда так.
Ну как я и написал за это в PHP отвечает параметр ignore_user_abort. Если вам есть что добавить, то я готов это добавить в статью.
0
На сколько я понимаю, если скрипт отправит что-то клиенту, после чего долгое время (больше чем указано в send_timeout) будет «молчать», то соединение закроется. Поправьте если я ошибаюсьСкрипт ничего клиенту не отправляет, этим в данном случае nginx занимается.
Фразу «клиент ничего не примет» следует понимать буквально: клиент не принял отправленных ему данных в течение заданного времени, nginx сделал write() в сокетный буфер, но последний так и остался в том же состоянии, нового события на запись не наступило. Ну а если все записанные данные в сокет успешно отправляются, то таймер выключается.
Ну как я и написал за это в PHP отвечает параметр ignore_user_abort. Если вам есть что добавить, то я готов это добавить в статью.Я в том сообщении процитировал конкретное ваше заявление. Вы полагаете, что у сервера всегда есть возможность узнать о том, что клиент нажал кнопку stop в браузере и закрыл соединение (если вообще закрыл). Нет, часто это невозможно сделать, пока не начнешь писать в сокет, а писать нечего, пока ваш скрипт не вернул ответ. Более того, если вы ещё и кэш включите, то даже в случае когда закрытие соединения было четко детектировано, с точки зрения php ничего не произойдет, поскольку нам нужно заполнить ячейку кэша. Даже если кэш не используются, то могут быть включены опции: fastcgi_ignore_client_abort и proxy_ignore_client_abort. PHP не общается с клиентом напрямую, а полагается только на то, как поведет себя сервер приложений, который взаимодействует с веб-сервером, но даже у последнего не всегда есть достаточно информации о том, что проихошло на той стороне.
— Что же касается статьи в целом, то это отличный пример того, как не надо делать обработку долгих задач. Проблеск этого понимания промелькнул только в конце статьи, да и то был испорчен витиеватым и неубедительным объяснением, почему обработку следует производить в фоне. На первый абзац из «Нагрузка на веб-сервер», можно только ответить: для этого люди и используют nginx!
Обработку следует производить не просто в фоне, а последовательно, с использованием очереди заданий и менеджера, который эту очередь разгребает. Потому, что ваш сервер в принципе может быть не в состоянии обрабатывать параллельно то количество задач, которое на него поступило в данный момент. В целом он вряд ли способен обрабатывать их эффективно, если количество CPU-bound потоков привышает число имеющихся в распоряжении вычислительных ядер.
Ну и да, в статье полностью перемешаны в винегрет CPU-bound и I/O-bound, т.е. задачи, требующие разных подходов для их решения. Да и решать такие задачи на php можно наверное только если ничего больше не знать, что уже само по себе должно быть моветон.
+2
Два чая, этому господину…
Всё ждал, кто же наконец предложит использовать очереди?
Всё ждал, кто же наконец предложит использовать очереди?
+2
Спасибо за критику, статья и вправду получилась немного сумбурной (мало опыта в написании статей). Но все же я не ставил своей целью описывать разные типы долгих задач и методы их решения. Я лишь хотел написать о факторах, которые могут помешать работе таких скриптов.
По поводу того, что не надо решать такие задачи на PHP, не соглашусь. Если у вас уже есть веб-приложение, написанное на PHP, со своими классами и библиотеками, и в нем вам нужно добавить, например, функцию импорта, в которой будут использоваться эти классы и библиотеки, то я не вижу смысла реализовывать ее на другом языке.
По поводу того, что не надо решать такие задачи на PHP, не соглашусь. Если у вас уже есть веб-приложение, написанное на PHP, со своими классами и библиотеками, и в нем вам нужно добавить, например, функцию импорта, в которой будут использоваться эти классы и библиотеки, то я не вижу смысла реализовывать ее на другом языке.
0
if (lockStart('script.php')) { // основной код скрипта ... lockStop('script.php'); }
Старайтесь избегать подобных подходов. Любая ошибка или непредусмотренная ситуация в скрипте и вы попали, как говорится. Вообще ПХП мало предназначен для подобного и лучше как можно больше вещей доверять профессионалам — ОС.
+2
с mysql все не однозначно, если вы налетели на mysql has gone away в транзакции то реконектиться нельзя, т.к часть данных уже уже потеряли. те влоб использовать подход с реконектом незя
+1
У php-fpm есть замечательная штука fastcgi_finish_request()
А вообще, если у Вас очень долгий скрипт после HTTP запроса от пользователя, то это потенциальная угроза DoS атаки.
А вообще, если у Вас очень долгий скрипт после HTTP запроса от пользователя, то это потенциальная угроза DoS атаки.
+2
Если скрипт запускается в ответ на HTTP-запрос, то пользователь может остановить выполнение запроса в своем браузере, в этом случае прекратит свою работу и PHP скрипт.
Это не совсем так. Не помню, как оно у апача, но в связке nginx + php-fpm от nginx команда уходит на php-fpm, и продолжает выполняться вне зависимости от того, стопнул юзер запрос или нет.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы «долгих» скриптов PHP