Такие лаги выглядят как если бы память машиины уходила в своп, когда вы ее дергаете запросом, эта память из свопа вылезает, как раз несколько секунд тратится
Еще возможно хостер оверселит дисковые подсистемы, т.е. ваш диск не ваш а используется еще клиентами хостера (это нормально, за счет оверселинга vps-ка и дешевле bare metal), т.е. ваши данные улетели из кеша, а диски нагружены другим клиентом, пока все это раскочегарится...
Найти причину можно экспериментами, рекомендую разместить на сайте простенькую страничку-тест, которая при открытии будет засекать время и выводить его в качестве ответа, затем делать что то, снова выводить и так по каждой предполагаемой причине зависания... т.е. последовательно выделить память, прочитать файл, прочитать файл по сети и т.п., делов на 5 -6 строчек, затем открывая ее в разное время со своей машины, смотреть тайминги.
уменьши тестируемое изображение в 2,3,4,.. раз и поочередно сравнивай с оригиналом
не уверен что это сработает от sharpness фильтров но попробовать можно
это мой вопрос
пока образ собирается совет, создать минимальный образ в котором ошибка воспроизводится, (ну маловероятно что там нужно nginx) и запости баг .. только хз куда, в докер?
решение не учитывает веса а еще из-за дыр в списке значений id это не будет работать как ожидается, но если завести специальное поле - счетчик и обновлять его у всех записей при удалении добавлении записей, то будет работать, только вот обновлять эффективно такой список не получится
у контроллера домена есть специальная роль - backup domain controller, если вы готовы для резервирования данных домена покупать соответствующую лицензию, почему нет.
восстаналивать бакап контроллера через файловую систему а не инструменты резервного копирования самого сервера, после того как вы к примеру там что то поменяли, - мягко говоря опасно и в теории даст сложнодиагностируемые проблемы
Ярослав Иванов, у него там 'толщина ширина и высота'
нет, конечно если там будут еще и другие атрибуты типа массы, формы, цвета и прочего то да, я про это и написал дальше
в подавляюще большом количестве случаев, если работаем с локальным временем а не античной историей к примеру или абстрактным будущим жизни звезд, то более чем достаточно, удобно и максимально быстро работать с unix timestamp, уходя в DateTime или иные форматы только по необходимости (которая происходит очень редко), а в 64bit с отрицательными значениями можно и везде (500 миллиард лет в секундах)
забудь про ob_... он тут совсем не причем,вообще пока не используй
еще раз, создавай картинку как ты сейчас создаешь в post скрипте, не важно сколько у тебя источников, хоть 100500, в конце создания изображения ты его сохраняешь одной командой с выводом в качестве ответа сервера imagepng($full, null);
Еще возможно хостер оверселит дисковые подсистемы, т.е. ваш диск не ваш а используется еще клиентами хостера (это нормально, за счет оверселинга vps-ка и дешевле bare metal), т.е. ваши данные улетели из кеша, а диски нагружены другим клиентом, пока все это раскочегарится...
Найти причину можно экспериментами, рекомендую разместить на сайте простенькую страничку-тест, которая при открытии будет засекать время и выводить его в качестве ответа, затем делать что то, снова выводить и так по каждой предполагаемой причине зависания... т.е. последовательно выделить память, прочитать файл, прочитать файл по сети и т.п., делов на 5 -6 строчек, затем открывая ее в разное время со своей машины, смотреть тайминги.