Изменение размера изображения PHP на лету против сохранения изображений с измененным размером

Я создаю сайт для обмена изображениями и хотел бы знать плюсы и минусы изменения размера изображений на лету с помощью PHP и сохранения измененных изображений.

Что быстрее?

Что надежнее?

Насколько велик разрыв между двумя методами в скорости и производительности?

Обратите внимание, что в любом случае изображения проходят через PHP-скрипт для статистики, такой как просмотры, или если разрешена горячая ссылка и т. Д., Поэтому не похоже, что это будет прямая ссылка для изображений, если я решу сохранить изображения с измененным размером.

Буду признателен за ваши комментарии или любые полезные ссылки по этой теме.


person Pablo    schedule 12.05.2010    source источник
comment
Хороший вопрос, мы могли бы подумать, что хранить миниатюры изображений - это плохо, потому что это создает дубликаты изображений, а также бесполезные данные при резервном копировании вашего веб-сайта.   -  person baptx    schedule 07.09.2015


Ответы (4)


Это звучит как преждевременная оптимизация. Знаете ли вы, сколько пользователей будет на вашем сайте / сколько вычислительных ресурсов придется на ваш сервер (ы)? Выбирайте самый простой (с точки зрения обслуживания) вариант, то есть изменяйте размер на лету, пока производительность не станет проблемой, а затем решите оттуда, что делать.

Возможно, стоит реализовать какое-то кеширование на стороне сервера ваших измененных изображений, если они, вероятно, будут многократно попадать в них, но я не думаю, что это нужно расширять до явного предварительного рендеринга.

person spender    schedule 13.05.2010
comment
Спасибо за совет. В настоящее время я кэширую все миниатюры, так как их будет много на одной странице, и оставил динамическое изменение размера для страницы изображения и параметров загрузки. - person Pablo; 13.05.2010
comment
Вы можете легко создать собственное приложение для изменения размера, ознакомьтесь с этим репозиторием: github.com/sadok-f/flyimg < / а> - person sadok-f; 04.01.2017
comment
Я бы также добавил, что, вероятно, лучше всего кэшировать миниатюры в отдельном каталоге кеша. Таким образом, вы не смешиваете эскизы с исходными изображениями и можете легко определить, сколько места на диске вы хотите потратить на кеширование. Таким образом, изменение размера «на лету» с ограниченным кэшированием позволит вам динамически настраивать компромисс между загрузкой системы и дисковым пространством. Кроме того, реализация очень модульная. - person Yeti; 16.08.2020

Это абсолютно несопоставимые вещи.

Фактически, изменение размера изображений на лету похоже на запуск DoS-атаки на ваш собственный сервер. Для изменения размера одного обычного изображения требуется больше ЦП и ОЗУ, чем для обслуживания одного обычного запроса к php-скрипту. Это УЖЕ оказывает огромное влияние на производительность. Но обычная миниатюра показывается не одна, а в цифрах. Таким образом, показывая только одну страницу галереи, вы создаете десятки процессов с большой нагрузкой, увеличивая нагрузку на сервер в десять и более раз.

Быстрый и грязный тест, чтобы подтвердить мои слова: давайте попробуем изменить размер относительно небольшого 1,3-мегапиксельного изображения.

$ /usr/bin/time --format="%MK mem %Es CPU time" /usr/bin/convert angry_birds_1280x800.jpg -resize 100x100 thumb.jpg
10324K mem 0:00.10s CPU time

Это заняло у нас 0,1 с, поэтому отображение 10 изображений для предварительного просмотра отнимет целую секунду вашего процессорного времени. Правильно написанная страница галереи PHP займет около 0,01 секунды. Таким образом, изменяя размер на лету, вы увеличиваете нагрузку на сервер в 100 раз.

То же и с памятью. Каждый процесс изменения размера потребляет не менее 10 МБ памяти (для изменения размера файла изображения размером 100 КБ!), А общая сумма составляет 100 МБ. В то время как обычный предел памяти для сценария PHP составляет всего 8 МБ, и он редко достигается.

Это реальные цифры из жизни.

Несколько забавная вещь, связанная с этой проблемой:
Точно тот же пользователь PHP, который легко выбрасывает 1000000 циклов процессора, в то же время невероятно ревнив, чтобы сэкономить 1 или 2! Это не фигура речи, вот пример того, о чем я говорю:
A похожий вопрос от кого-то, чью большую озабоченность в то же время ничтожно мало, как разница в скорости между константами, переменными или массивами переменных. И кто недавно столкнулся с проблемой исчерпания разрешенного размера памяти, как будто такой катастрофы мало.

На этом сайте есть ТОННА вопросов и ответов, обсуждаются наносекундная разница в скорости любых операций, ответы на них с неиссякаемым достоинством, проводятся тесты миллионов итераций, чтобы показать абсолютно незначительную разницу между однократными операциями в несколько циклов процессора каждая.

И в то же время есть подобные вопросы - по поводу огромной, несравнимой разницы в производительности между двумя подходами, которая кажется автору просто равной.

Это проблема обычного пользователя PHP и этого сайта.
У первых просто нет возможности отличить реальные вещи от микроскопических.
А у последних нет механизма проверки правильности ответов на вопросы - все отвечали с одинаковым энтузиазмом , даже если два вопроса противоречат друг другу (и оба здравого смысла).

person Your Common Sense    schedule 27.02.2012
comment
Вопрос OP сам по себе просто спрашивает, какой способ лучше, и, конечно же, предварительное изменение размера изображений и их сохранение с измененным размером - это огромный прирост производительности и несравнимые вопросы. Не считая того факта, что при использовании метода на лету изменение размера одного и того же изображения дважды (как минимум) является худшей производительностью, которую вы можете получить. Но если используется служба изменения размера изображения на лету с некоторым CDN перед ним, поэтому каждое изображение кэшируется, это может быть очень хорошим вариантом. На самом деле, я могу сказать, что это ленивая версия хранения изображений с измененным размером на диск. - person eAbi; 21.06.2015

Динамическое изменение размера может быть дорогостоящей процедурой (по времени) в зависимости от исходного размера изображений. Я делал это в производственных системах, но когда у меня есть выбор, я настоятельно рекомендую кэширование на диск. В конце концов, дисковое пространство дешево, а время загрузки - это все, что есть в Интернете. Даже если вы просто кешируете миниатюры определенного размера и выполняете динамическое изменение размера повсюду, вы можете значительно сократить время загрузки списков изображений в стиле галереи.

person warrenm    schedule 13.05.2010
comment
Вы правы, у меня на живом хосте доступно 400 ГБ. Думаю, я просто сохраню все изображения с измененным размером. Спасибо, что поделился. - person Pablo; 13.05.2010

Я настоятельно рекомендую вам кэшировать изображения и НЕ изменять размер на лету.

изменение размера изображений очень интенсивно использует процессор и память для вашего сервера.

Если у вас есть галерея изображений, которая будет масштабироваться на лету, страница будет загружать изображения медленно, скажем, за 3-10 секунд, в зависимости от исходного размера файла.

При изменении размера требуется около 3 байтов на пиксель вашей памяти. Итак, если у вас есть изображение размером 1000x1000, которое нужно изменить, это займет около 3 МБ памяти. Если на одной из ваших веб-страниц много изображений с изменяемым размером на лету, скажем, 20, это займет около 60 МБ ОЗУ вашего сервера. Возможно, нет, поскольку большинство клиентов одновременно запрашивают только 4 изображения, но 12 МБ по-прежнему много для загрузки страницы. Я бы масштабировал только на лету, если исходное изображение меньше 100x100 пикселей.

СОВЕТ. Отличной библиотекой для масштабирования и сохранения больших пальцев является PhpThumb.

person Vidar Vestnes    schedule 13.05.2010
comment
Спасибо за ввод, я демонстративно сохраняю изображения в файловой системе. - person Pablo; 13.05.2010