Ошибка Maximum execution time exceeded означает, что PHP-скрипт работал дольше разрешённого лимита (обычно 30-60 секунд) и был принудительно остановлен. Лимит задаётся директивой max_execution_time в настройках PHP. Просто поднять его - значит спрятать симптом: правильный путь - найти, на чём скрипт теряет время: медленный SQL-запрос, цикл по огромной выборке или ожидание внешнего сервиса. Разбираем, как вычислить узкое место и в каких случаях лимит всё же можно увеличить.
Почему PHP не укладывается в лимит: типовые пожиратели времени
- Медленные SQL-запросы - фильтр или поиск по каталогу без нужных индексов перебирает всю таблицу
- Циклы по всей базе - пересчёт цен или остатков по 50 000 товаров за один заход
- Внешние API - платёжка, служба доставки или курс валют отвечают по 20-30 секунд, скрипт послушно ждёт
- Генерация файлов - выгрузки в Excel, карта сайта, нарезка картинок на лету
- Агенты Битрикс на хитах - фоновые задачи платформы выполняются за счёт случайного посетителя
Как найти узкое место: пошаговый план
- Дочитайте ошибку до концаВ ней указаны файл и строка, где скрипт остановился. Это место, где время закончилось, - не всегда причина, но отправная точка.
- Включите лог медленных запросовSlow log в MySQL покажет, уходит ли время в базу. Один запрос на 40 секунд - и диагноз готов.
- Откройте монитор производительности БитриксШтатный инструмент платформы: топ страниц по времени с разбивкой на PHP и SQL. Запустите на сутки и снимите сливки.
- Проверьте внешние вызовыНайдите обращения к чужим API и убедитесь, что таймауты заданы явно: ждать ответа 5 секунд, а не вечность.
- Замерьте подозрительный участокЛогирование времени по шагам скрипта за один прогон сужает круг до конкретной функции.
Где обычно узкое место: карта симптомов
| Симптом | Вероятное узкое место |
|---|---|
| Падает одна страница фильтра или поиска | SQL без индексов, тяжёлая выборка |
| Падает импорт или выгрузка | Объём данных: нужны порции и запуск по cron |
| Падают случайные страницы в часы пик | Перегружен сервер или соседи по хостингу |
| Падает оформление заказа | Внешние API платёжек и доставок без таймаутов |
| Падает всё подряд после обновления | Конфликт кода - смотрите разбор в статье про ошибку 500 |
Страница или импорт не укладываются в лимит?
Профилируем код, оптимизируем запросы и вынесем тяжёлые задачи в фон. С 2013 года, 450+ проектов на Битрикс - смета до начала работ.
Когда поднимать max_execution_time, а когда чинить код
Поднимать лимит уместно для редких админских операций: разовый импорт, миграция, генерация большого отчёта. Для страниц, которые открывают посетители, увеличение лимита - капитуляция: никто не ждёт полминуты, люди уходят к конкурентам раньше. Если сайт в целом отвечает медленно, начните с материала как ускорить сайт - там разобраны и серверная, и клиентская части.
Профилактика: чтобы лимит больше не стрелял
Раз в квартал смотрите монитор производительности и лог медленных запросов: деградация накапливается незаметно, каталог и база растут. На абонентской поддержке мы делаем это регулярно и чиним медленные места до того, как они превратятся в ошибки на экране.
Частые вопросы про max_execution_time
Ошибка появляется при загрузке большого прайса. Что делать?
Можно ли просто поставить max_execution_time равным 300?
Почему на старом хостинге работало, а на новом падает?
Это то же самое, что ошибка 504 Gateway Timeout?
Вывод: ошибка про execution time - это секундомер, который честно говорит, что где-то в коде течёт время. Найти течь можно за вечер по логам и монитору производительности, а если хочется сразу к результату - закажите доработку сайта: продиагностируем бесплатно и назовём цену до старта.
