Увеличить время выполнения скрипта php nginx
Увеличиваем таймауты uwsgi+nginx (обходим 504 Gateway Time-out)
Если на вашем веб-сервере есть запросы, которые выполняются дольше 60 секунд, вы что-то делаете не так. Даже секунда на запрос — это ужасно долго, а 60 — те, что по умолчанию в nginx — просто ужас. Однако, есть ряд случаев, когда это необходимо/допустимо.
Если на вашем веб-сервере есть запросы, которые выполняются дольше 60 секунд, вы что-то делаете не так. Даже секунда на запрос — это ужасно долго, а 60 — те, что по умолчанию в nginx — просто ужас. Однако, есть ряд случаев, когда это необходимо/допустимо.
В конфиге uwsgi.ini увеличим время harakiri (до 10 минут):
В конфиге nginx увеличим timeoutы:
Ну или как вы делаете перезапуск юнитов/тасков uwsgi, nginx.
Альтернативы увеличению тайм-аутов
Если у вас каждый запрос выполняется более 60 секунд — было бы неплохо посмотреть, где тратится время. Поискать debug-toolbarы под ваш фреймворк, посмотреть explain sql-запросов (если используете sql базу данных).
Если это разовые операции / пересчёт статистики / выгрузка данных, то есть 2 простых способа сделать эти запросы менее «вредными» для работы сервиса.
Отложенное выполнение в очереди, отсылка по почте
Часто менеджеры / маркетологи довольны наличию выгрузок / пересчёту статистики не из веб-интерфейса, а, например, из почты.
Тогда можно оставить в покое веб-интерфейс и сделать всё через воркеры. В этом случае нам потребуется очередь задач. Такие очереди обычно основаны на Redis или RabbitMQ (и прочих AMQP реализациях). В частности, для python можно воспользоваться python-rq. Для django есть его обёртка — django-rq, в которой можно даже смотреть на кол-во задач в очереди и перезапускать упавшие задачи.
Отправлять результаты можно, например, по почте.
Это вариант предоставления информации после запроса. Очередной пример масштабирования по времени.
Выполнение по cron, сохранение на сервере
С другой стороны, может быть ситуация, когда несколько менеджеров будут пользоваться статистикой. Сама же статистика их устраивает за предыдущий день. Тогда будет рационально предгенерировать файлы статистики. Выбираем наименее нагруженное для сервера время, добавляем в cron задачу (программу, которую мы написали) по генерации статических файлов отчётов. Ну и добавляем для них правило в nginx.
Это вариант предоставления информации до запроса (прогрев кеша). Также является примером масштабирования по времени.
Как увеличить память и время для PHP скриптов
Настройки потребления ресурсов в PHP скриптах можно установить в главном конфигурационном файле php.ini, а также в самих скриптах.
В файле php.ini за это отвечают директивы из раздела Resource Limits (ограничение потребления ресурсов).
Как увеличить память для PHP скриптов
Для этого в файле php.ini найдите и отредактируйте директиву:
Эта директива задаёт максимальное время в секундах, в течение которого скрипт должен полностью загрузиться. Если этого не происходит, парсер завершает работу скрипта. Этот механизм помогает предотвратить зависание сервера из-за плохо написанного скрипта. По умолчанию на загрузку даётся 30 секунд. Если PHP запущен из командной строки, это значение по умолчанию равно 0.
На максимальное время выполнения не влияют системные вызовы, потоковые операции и т.п.
При работе в безопасном режиме эту настройку нельзя изменить функцией ini_set(). Если значение все же нужно изменить, надо либо выключить безопасный режим, либо изменить значение прямо в php.ini.
Веб-серверы обычно имеют свои настройки тайм-аута, по истечении которого сами завершают выполнение скрипта PHP. В Apache есть директива Timeout, в IIS есть функция CGI timeout. В обоих случаях по умолчанию установлено 300 секунд. Точные значения можно узнать из документации к веб-серверу.
Функция для увеличения и ограничения времени выполнения PHP
Функция set_time_limit ограничивает время выполнения скрипта.
Она задает время в секундах, в течение которого скрипт должен завершить работу. Если скрипт не успевает, вызывается фатальная ошибка. По умолчанию дается 30 секунд, либо время, записанное в настройке max_execution_time в php.ini (если такая настройка установлена).
При вызове set_time_limit() перезапускает счетчик с нуля. Другими словами, если тайм-аут изначально был 30 секунд, и через 25 секунд после запуска скрипта будет вызвана функция set_time_limit(20), то скрипт будет работать максимум 45 секунд.
Возвращаемые значения: возвращает TRUE в случае успеха, иначе FALSE.
Внимание: эта функция не работает, если PHP работает в безопасном режиме. Обойти это ограничение можно только выключив безопасный режим или изменив значение настройки в php.ini.
Замечание: функция set_time_limit() и директива max_execution_time влияют на время выполнения только самого скрипта. Время, затраченное на различные действия вне скрипта, такие как системные вызовы функции system(), потоковые операции, запросы к базам данных и т.п. не включаются в расчет времени выполнения скрипта. Это не относится к системам Windows, где расчитывается абсолютное время выполнения.
Обе set_time_limit(…) и ini_set(‘max_execution_time’,…); не учитывают время, потраченное функциями sleep, file_get_contents, shell_exec, mysql_query и некоторыми другими.
Увеличение выделенной памяти для PHP скриптов
Директива в файле php.ini
задаёт максимальный объем памяти в байтах, который разрешается использовать скрипту. Это помогает предотвратить ситуацию, при которой плохо написанный скрипт съедает всю доступную память сервера. Для того, чтобы убрать ограничения, установите значение этой директивы в -1.
В версиях до PHP 5.2.1 для использования этой директивы, она должна была быть указана на этапе компиляции. Так, ваша строка конфигурации должна была включать: —enable-memory-limit. Эта опция компиляции была также необходима для использования функций memory_get_usage() и memory_get_peak_usage() до версии 5.2.1.
Если используется целое число, то значение измеряется байтами. Вы также можете использовать сокращённую запись.
Доступные опции: K (для килобайт), M (для мегабайт) и G (для гигабайт; доступна начиная с PHP 5.1.0); они регистронезависимы. Все остальное считается байтами. 1M равно одному мегабайту или 1048576 байтам. 1K равно одному килобайту или 1024 байтам. Эти сокращения вы можете использовать в php.ini и в функции ini_set(). Обратите внимание, что числовое значение приводится к типу integer; например, 0.5M интерпретируется как 0.
Увеличение времени парсинга данных из запроса.
Директива в файле php.ini
задаёт максимальное время в секундах, в течение которого скрипт должен разобрать все входные данные, переданные запросами вроде POST или GET. Это время измеряется от момента, когда PHP вызван на сервере до момента, когда скрипт начинает выполняться. Значение по умолчанию -1, что означает, что будет использоваться max_execution_time. Если установить равным 0, то ограничений по времени не будет.
При запуске в командной строке значение директивы установлено на -1 (неограниченно).
Увеличение глубины вложенности входных переменных
Директива в файле php.ini
Ограничение на количество входных переменных
Директива в файле php.ini
Внимание: после внесения изменений в файл php.ini необходимо перезагрузить веб-сервер, чтобы изменения вступили в силу.
Проверка использование ресурсов
Функция getrusage получает информацию об использовании текущего ресурса.
Возвращаемые значения: возвращает ассоциативный массив, содержащий данные возвращённые из системного вызова. Имена элементов соответствуют документированным именам полей.
Пример использования getrusage():
Увеличение разрешённого размера файлов для загрузки на сервер
Кроме описанных ограничений на потребление непосредственных ресурсов веб-сервера, также имеются ограничения, которые оказывают косвенное воздействие на ресурсы: например, загрузка слишком большого файла на сервер может потребовать большого количества ресурсов для его обработки, либо привести к переполнению дискового хранилища сервера. Поэтому существуют дополнительные лимиты, включённые в другие разделы конфигурационного файла помимо Resource Limits.
В частности, директива
устанавливает максимальный размер закачиваемого файла.
Если используется целое число, значение измеряется байтами. Вы также можете использовать сокращённую запись, которая описана чуть выше.
Максимально допустимый размер данных, отправляемых методом POST
Методом пост могут отправляться как текстовые данные (например, при отправке комментария на сайт), так и файлы. Если вы увеличили значение upload_max_filesize чтобы иметь возможность загружать файлы большего размера на сайт, то также нужно увеличить и значение директивы:
которая устанавливает максимально допустимый размер данных, отправляемых методом POST. Это значение также влияет на загрузку файлов. Для загрузки больших файлов это значение должно быть больше значения директивы upload_max_filesize. В сущности, memory_limit должна быть больше чем post_max_size. Если используется integer, значение измеряется байтами. Вы также можете использовать сокращённую запись, которая описана выше. Если размер POST-данных больше чем post_max_size, суперглобальные переменные $_POST и $_FILES будут пустыми. Это можно отследить различными способами, например передав $_GET переменную в скрипт, обрабатывающий данные, т.е.
Проблемы «долгих» скриптов PHP
Внешний таймаут
В первую очередь нужно установить подходящее значение параметра max_execution_time в конфиге PHP.
Веб-сервер может также проксировать запросы на другой веб-сервер, который и запустит PHP скрипт (не редкий пример, nginx — фронтенд, apache — бэкэнд). В этом случае на проксирующем веб-сервере необходимо также настраивать таймаут проксирования. Для apache ProxyTimeout, для nginx proxy_read_timeout.
Прерывание пользователем
Если скрипт запускается в ответ на HTTP-запрос, то пользователь может остановить выполнение запроса в своем браузере, в этом случае прекратит свою работу и PHP скрипт. Если же требуется, чтобы скрипт продолжил свою работу даже после остановки запроса, установите в TRUE параметр ignore_user_abort в конфиге PHP.
Потеря открытых соединений
В таких случаях следует в первую очередь попробовать увеличить таймаут соединения. Например, для MySQL можно выполнить запрос (спасибо Snowly)
Параллельный запуск
В таких случаях можно использовать блокировку используемых ресурсов, но эта задача всегда решается индивидуально. Либо можно просто проверять, не запущена ли другая копия этого скрипта, и либо подождать завершения его работы, либо завершить текущий запуск. Для этого можно просматривать список запущенных процессов, либо использовать блокировку запуска самого скрипта, что то вроде:
Нагрузка на веб-сервер
В случаях, когда долгие скрипты запускаются через веб-сервер, соединение клиента с этим самым веб-сервером остается открытым до тех пор, пока не отработает скрипт. Это не есть хорошо, т.к. задача веб-сервера как можно быстрее обработать запрос и отдать результат. Если же соединение остается висеть, то один из воркеров (процессов) веб-сервера на долгое время будет занят. А если одновременно будет запущено достаточно много таких скриптов, то они могут занять все (ну или почти все) свободные воркеры (для apache см. MaxClients), и веб-сервер просто не сможет обрабатывать другие запросы.
Поэтому следует при обработке запроса пользователя, запускать скрипт в фоновом режиме через php-cli, чтобы не нагружать веб-сервер, а пользователю отвечать что его запрос обрабатывается. При необходимости можно периодически проверять состояние обработки при помощи AJAX запросов.
Вот, пожалуй, и все что я могу рассказать по этой теме. Надеюсь, для кого-то будет полезным.
Как увеличить время выполнения PHP-скрипта?
Если вы разрабатываете крупный проект, то на обработку некоторых данных ему может потребоваться большое количество времени. На разных хостингах стоят свои лимиты на такие действия, и если сюда вас привела необходимость увеличить это время – то я подробно расскажу, как это можно сделать.
Чтобы вы понимали, о чем идет речь, приведу небольшой пример. При выходе за выставленные рамки времени вы можете получить следующего рода ошибку:
Я расскажу о 4-х способах, как избавиться от нее.
Но стоить начать с того, что в каждом отдельном случае все перечисленные способы могут не работать, так как некоторые хостинг-провайдеры запрещают самим изменять этот параметр.
Увеличение времени выполнения PHP-скрипта через конфигурационный файл php.ini
В качестве первого способа для увеличения времени выполнения скрипта мы будем использовать файл конфигурации php.ini.
Для того чтобы точно узнать, где находится этот файл, прочитайте эту статью.
Открываете его удобным для вас способом и в самый низ вставляете:
Где «300» означает 300 секунд (меняете на свое). Этот файл, к сожалению, не на всех хостингах доступен пользователям для редактирования.
Увеличение времени выполнения PHP-скрипта через встроенную функцию «ini_set»
Второй способ основывается на использовании функции «ini_set». Ее вы вставляете непосредственно в сам файл скрипта, желательно в самый верх. Пример:
Здесь значение «300» вы также сменяете на нужное вам в секундах. Обратите внимание, что при использовании PHP в безопасном режиме эта функция будет недоступна.
Увеличение времени выполнения PHP-скрипта через встроенную функцию «set_time_limit»
Третий способ, наверное, один из самых популярных – использование функции «set_time_limit» для изменения времени выполнения скрипта. Также используется непосредственно в самом файле PHP. Пример:
Здесь «300» вы также изменяете на нужное вам значение. Вставлять код желательно в самом верху.
Последний вариант заключается в редактировании файла .htaccess, который находится в корне вашего сайта (если таковой отсутствует – создайте его).
В самый верх этого файла вставьте:
Значение «300» вы также меняете на свое.
Обратите внимание, что во всех случаях время выполнения скрипта указывается в секундах. Помимо этого, значение параметра во всех способах может принимать «0», что означает неограниченное время выполнения.
Как узнать, сколько времени отведено на выполнение PHP-скрипта?
После того, как одним из способов вы попытались изменить время выполнения скрипта, нужно узнать, действительно ли у вас это получилось.
Для этого создайте PHP-файл в корне вашего сайта, где выведите значение установленного времени:
Если время равняется тому, что вы указали – поздравляем вас, вы достигли желаемой цели. В противном же случае прочитайте статью еще раз, напишите в комментариях о вашей проблеме или направьте ее вашему хостинг-провайдеру.
Ускоряем Nginx за 5 минут
Попытайтесь повторить это сами
Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.
На всякий пожарный, создадим бэкап исходного конфига.
А теперь можно и похимичить!
Начнём с директивы worker_processes. Если Nginx выполняет работу нагружающую процессор (например SSL или gzipping), то оптимально установить эту директиву в значение, равное количеству ядер процессора. Выигрыш при большем значении вы получите только в случае обработки очень большого количества статики.
Также, директива worker_processes, умноженная на worker_connections из секции event, даст максимально возможное количество клиентов.
Теперь разберёмся с логированием. Во-первых, оставим логирование только критических ошибок.
Если вы совсем бесстрашны и хотите отключить логирование ошибок целиком, то помните, что error_log off вам не поможет. Вы просто получите весь лог в файле off. Для отключения логирования ошибок надо делать так:
А вот логи доступа не так страшно отключить полностью.
Или, хотя бы, включить буфер чтения / записи.
Для обработки подключений Nginx поддерживает ряд методов. Наиболее эффективным для Linux является метод epoll.
Для того, чтобы Nginx пытался принять максимальное количество подключений, необходимо включить директиву multi_accept. Однако при слишком маленьком значении worker_connections, их лимит может быть очень быстро исчерпан.
Директива sendfile активирует копирование данных между файловыми дескрипторами средствами ядра, что намного эффективнее связки read() + write(), которая требует обмена данными с пользовательским пространством.
После включения sendfile, можно заставить Nginx отправлять заголовки HTTP-ответов одним пакетом, а не отдельным частями.
Для keep-alive подключений можно выключить буферизацию (алгоритм Нейгла). Это будет полезно при частом запросе маленьких объёмов данных в режиме реального времени, без получения немедленного ответа, когда важна своевременная доставка данных. Классический пример — события наведения мышкой.
Стоит обратить внимание на ещё две директивы для keep-alive подключений. Их назначение выглядит очевидным.
Чтобы высвободить дополнительную память, выделенную под сокеты, включите директиву reset_timedout_connection. Она разрешит серверу закрывать подключение тех клиентов, которые перестали отвечать.
Ещё можно существенно уменьшить тайм-ауты для директив client_body_timeout и send_timeout (дефолтное значение обеих — 60 секунд). Первая — ограничивает время на чтение тела запроса от клиента. Вторая — время ответа клиенту. Таким образом, если клиент не начнёт читать данные в указанный промежуток времени, то Nginx закроет подключение.
И, конечно же, сжатие данных. Плюс — единственный и очевидный: уменьшение размера пересылаемого трафика. Минус — единственный и очевидный: не работает для MSIE 6 и ниже. Отключить сжатие для этих браузеров можно директивой gzip_disable, указав в качестве значения специальную маску “msie6”, которая соответствует регулярному выражению “MSIE 5\.”, но работает быстрее (спасибо hell0w0rd за комментарий).
Пожалуй, это всё, о чём я хотел рассказать. Скажу лишь ещё раз, что не стоит копировать приведенные настройки один в один. Я советую применять их по одной, каждый раз запуская какую-нибудь утилиту для нагрузочного тестирования (например, Tsung). Это весьма важно для понимания, какие настройки реально ускоряют ваш веб-сервер. Методичность в тестировании сэкономит вам уйму времени.