Изменение размера изображения на лету против хранения измененных изображений - PullRequest
24 голосов
/ 13 мая 2010

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

Что быстрее?

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

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

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

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

Ответы [ 4 ]

29 голосов
/ 27 февраля 2012

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

Изменение размера изображений на лету фактически похоже на выполнение 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! Это не фигура речи, вот пример того, о чем я говорю:
аналогичный вопрос от кого-то, чье большое беспокойство в то же время ничтожно мало, как разница в скорости между константами, переменными или массивами переменных . А кто недавно столкнулся с проблемой разрешенного объема памяти , как будто такой катастрофы было недостаточно.

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

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

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

22 голосов
/ 13 мая 2010

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

16 голосов
/ 13 мая 2010

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

15 голосов
/ 13 мая 2010

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

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

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

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

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

...