производительность — Совместное использование Cron Jobs и GD
У меня есть клиентский веб-сайт, который требует от них загрузки изображения, и при этом мой скрипт сохранит около 25-30 вариантов изображения на сервер с помощью библиотеки GD. Из-за большого количества изображений в настоящее время клиент ожидает продолжения на сайте очень долго, пока все изображения не будут созданы и сохранены. До тех пор они не могут продолжить, поэтому мы получаем высокий уровень клиентов, покидающих сайт.
Можно ли после загрузки вместо сохранить URL-адрес изображения в записи таблицы базы данных, а затем создать скрипт php, который создает 25-30 изображений, извлекающих каждую запись в базе данных и запускаемых каждые 5 минут дня с помощью cronjob. Таким образом, он позволяет клиенту продолжить просмотр веб-сайта и автоматически создавать изображения «в фоновом режиме».
Будет ли все это происходить на заднем плане, вызывать какие-либо проблемы со скоростью моего сайта? Замедлит ли это сайт для пользователей, особенно если его используют 10-100 клиентов одновременно?
Решение
При обработке сценария PHP изображения не будут вызывать больше задержек в задании cron, чем когда клиент загружает изображение и ожидает завершения обработки в реальном времени. Короче говоря, нет там нет дополнительный влияние этого подхода.
Суть в том, что вы должны убедиться, что ваша работа cron основана на самосознании и не создает совпадений. Например, если cron запускается и занимает более 5 минут для выполнения своей текущей задачи, что произойдет, когда второй cron раскрутится и начнет обрабатывать другое изображение (или то же самое, если вы не реализовали очередь должным образом)? Ну, теперь у вас есть два бегущих крона, сражающихся за ресурсы. Что означает, что второй, скорее всего, займет более 5 минут. В конце концов вы попадаете в точку с 3, 4 и т. Д., Бегущими одновременно. Поэтому убедитесь, что ваши кроны «загружаются» только в том случае, если их еще нет.
При этом, вероятно, лучше всего, если бы другой сервер обрабатывал изображения в зависимости от размера сайта вашего клиента и интенсивности его трафика. В кластере может быть облачный сервер с вашим рабочим сервером сайта, который может подключаться через локальную сеть для доступа к изображению, его обработки и возврата 25-30 копий на сервер в соответствующем месте. Таким образом, ваша очередь обработки занимает 0 ресурсов общедоступного веб-сервера и не влияет на скорость самого сайта.
Другие решения
Я предлагаю начать смотреть на очереди, более конкретно Gearman.
Это уменьшит время загрузки ваших клиентов, так как вы можете перенести генерацию изображений на отдельный сервер. И он легко масштабируется на нескольких серверах, если вам нужна большая вычислительная мощность.
Конечно, вы можете хранить PATH изображения на вашем сервере и обрабатывать его позже.
создайте скрипт php, который при запуске создает файл LOCK, т. е. «/tmp/imgprocessor.lock», и удаляет его в конце, если cron запускает новый процесс, вы сначала проверяете, что файл не существует.
Я бы сохранял загруженные изображения в ie pathtoimages / toprocess / и удалял каждое после обработки или перемещал в другое место. Есть новые изображения в то есть / обработано /
Таким образом, вам не нужно запрашивать в БД путь к изображениям, а просто обрабатывать то, что находится в папке «toprocess», и вы можете просто иметь UNIQ_NAME_OF_IMAGE в таблице. В вашем веб-скрипте перед загрузкой oage проверьте, существует ли UNIQ_NAME_OF_IMAGE в папке «обработано», и если да, отобразите его …
От нагрузки на сервер зависит, сколько изображений у вас изначально и какие размеры, обработка изображений может быть тяжелой на сервере, но обработка 1000 пользователей * 30 изображений не будет сложной задачей, как я уже сказал, зависит от размера изображений.
ПРИМЕЧАНИЕ: если вы идете по этому пути, вам нужно убедиться, что при запуске cron ERROR журнал также выводится в некоторый файл журнала. Сценарий Cron должен быть пуленепробиваемым, т. Е. В случае сбоя по какой-либо причине файл LOCK останется, поэтому обработки больше не будет, вам нужно будет удалить его вручную (или создать собственный обработчик ошибок, который удаляет его и, возможно, отправляет несколько писем), вам следует периодически проверяйте файл журнала, чтобы знать, что происходит.