Жил себе поживал проект на впс от известного мокрого провайдера, функции свои выполнял и все было просто замечательно. Как говорится ничто не предвещало…
Но, однажды, пользователи стали жаловаться, что одна конкретная страничка при определенных обстоятельствах стала вываливаться в 502, чего ранее не наблюдалось.
Как понятно из заголовка, проект крутится на php-fpm, прикрытом nginx. В основе проекта *MVC-движок собственной разработки (так сложилось исторически) построенный на DBSimple + Smarty и заточенный под тотальный AJAX.
Забегая вперед скажу, что проблему решить удалось, однако обо все по порядку.
Как только стало известно о проблеме, я первым делом стал выяснять обстоятельства, при которых ошибка воспроизводилась. Страничка, на которой возникла проблема, является самым тяжелым отчетом из всех, что генерирует проект, и по дефолту, без фильтров и критериев, отчет получается относительно ресурсоемкий, однако не настолько, чтобы выбрать таймауты либо лимиты памяти.
Тем не менее при выставленных фильтрах проблема исчезала. Казалось бы вот оно решение? Но полная форма отчета периодически требуется для работы и как-то «обрезать» отчет не вариант…
Смотрю логи — а там ничего криминального, кроме подозрительно обрезанных на половине записей…
Хуже того, локально на девелоперской версии проблема не воспроизводится от слова совсем…
Очень странно…
Внезапно выяснилось, что проблема возникает только если перейти на страничку с любой другой странички, т.е. послать в заголовках реферер, а если заходить на страничку напрямую, в самом тяжелом ее варианте — то все отрабатывает нормально…
Что называется все чудесатее и чудесатее…
Всевозможные игры с конфигом nginx и php-fpm результатов не дали от слова совсем, даже обновление nginx до актуальной версии…
По логике вещей следующим этапом должна идти отладка кода, что и было реализовано.
Первым делом отключил вьюху, проверил как работают модель с контроллером — полет нормальный. Область поисков сузилась до вьюхи, а конкретнее залипало на вызове $smarty->fetch(...)…
Внезапно виновником проблемы оказалась библиотека Smarty. Движок имеет давнюю историю и шаблонизатор давненько не обновлялся, была подключена версия 3.1.7 при том, что актуальная версия 3.1.29
Здравый смысл подсказал, что проще всего попробовать обновить Smarty до актуальной версии и посмотреть исчезнет ли проблема.
С наскоку ничего не вышло, т.к. в версии 3.1.29 оказалась поломалась поддержка «dotted notation» для ассоциативных массивов, переданных в Smarty из PHP, причем не полностью, а как-то так хитровыдуманно. Опытным путем было выяснено, что данная проблема возникает начиная с версии 3.1.23.
И Бог бы с ним, да уж слишком много кода шаблонов завязано на то, что поломалось, и тотальный рефакторинг шаблонов не входил в мои планы от слова совсем. Поэтому пришлось подбирать версию, где прежний вариант «еще работал», ею оказалась версия 3.1.21.
После наката обновления Smarty проблема с ошибкой 502 исчезла…
Безусловно, расследование получилось достаточно поверхностным, и истинные причины проблемы выявлены не были. Можно сказать мне повезло решить проблему малой кровью, быстро и не вникая в дебри. Буквально по принципу необходимого и достаточного.
Если бы предпринятые меры не привели к результату, расследования были бы продолжены до победного.
Я подозреваю, что Smarty падала скорее всего из-за объёма передаваемых в нее для рендеринга данных, либо на циклах формирования строк таблицы.
Но вот как это было связано с полем реферер в заголовках я так и не смог понять…
Но, однажды, пользователи стали жаловаться, что одна конкретная страничка при определенных обстоятельствах стала вываливаться в 502, чего ранее не наблюдалось.
Как понятно из заголовка, проект крутится на php-fpm, прикрытом nginx. В основе проекта *MVC-движок собственной разработки (так сложилось исторически) построенный на DBSimple + Smarty и заточенный под тотальный AJAX.
Забегая вперед скажу, что проблему решить удалось, однако обо все по порядку.
Как только стало известно о проблеме, я первым делом стал выяснять обстоятельства, при которых ошибка воспроизводилась. Страничка, на которой возникла проблема, является самым тяжелым отчетом из всех, что генерирует проект, и по дефолту, без фильтров и критериев, отчет получается относительно ресурсоемкий, однако не настолько, чтобы выбрать таймауты либо лимиты памяти.
Тем не менее при выставленных фильтрах проблема исчезала. Казалось бы вот оно решение? Но полная форма отчета периодически требуется для работы и как-то «обрезать» отчет не вариант…
Смотрю логи — а там ничего криминального, кроме подозрительно обрезанных на половине записей…
Хуже того, локально на девелоперской версии проблема не воспроизводится от слова совсем…
Очень странно…
Внезапно выяснилось, что проблема возникает только если перейти на страничку с любой другой странички, т.е. послать в заголовках реферер, а если заходить на страничку напрямую, в самом тяжелом ее варианте — то все отрабатывает нормально…
Что называется все чудесатее и чудесатее…
Всевозможные игры с конфигом nginx и php-fpm результатов не дали от слова совсем, даже обновление nginx до актуальной версии…
По логике вещей следующим этапом должна идти отладка кода, что и было реализовано.
Первым делом отключил вьюху, проверил как работают модель с контроллером — полет нормальный. Область поисков сузилась до вьюхи, а конкретнее залипало на вызове $smarty->fetch(...)…
Внезапно виновником проблемы оказалась библиотека Smarty. Движок имеет давнюю историю и шаблонизатор давненько не обновлялся, была подключена версия 3.1.7 при том, что актуальная версия 3.1.29
Здравый смысл подсказал, что проще всего попробовать обновить Smarty до актуальной версии и посмотреть исчезнет ли проблема.
С наскоку ничего не вышло, т.к. в версии 3.1.29 оказалась поломалась поддержка «dotted notation» для ассоциативных массивов, переданных в Smarty из PHP, причем не полностью, а как-то так хитровыдуманно. Опытным путем было выяснено, что данная проблема возникает начиная с версии 3.1.23.
И Бог бы с ним, да уж слишком много кода шаблонов завязано на то, что поломалось, и тотальный рефакторинг шаблонов не входил в мои планы от слова совсем. Поэтому пришлось подбирать версию, где прежний вариант «еще работал», ею оказалась версия 3.1.21.
После наката обновления Smarty проблема с ошибкой 502 исчезла…
Безусловно, расследование получилось достаточно поверхностным, и истинные причины проблемы выявлены не были. Можно сказать мне повезло решить проблему малой кровью, быстро и не вникая в дебри. Буквально по принципу необходимого и достаточного.
Если бы предпринятые меры не привели к результату, расследования были бы продолжены до победного.
Я подозреваю, что Smarty падала скорее всего из-за объёма передаваемых в нее для рендеринга данных, либо на циклах формирования строк таблицы.
Но вот как это было связано с полем реферер в заголовках я так и не смог понять…