Изменение размера изображения на лету против хранения измененных изображений
Я создаю сайт для обмена изображениями и хотел бы узнать плюсы и минусы изменения размера изображений на лету с помощью PHP и сохранения размеров изображений.
Что быстрее?
Что является более надежным?
Насколько велик разрыв между двумя методами в скорости и производительности?
Обратите внимание, что в любом случае изображения проходят через PHP-скрипт для статистики, такой как представления, или если разрешены горячие ссылки и т. Д., Поэтому не похоже, что это будет прямая ссылка на изображения, если я решу сохранить изображения с измененным размером.
Буду признателен за ваши комментарии или любые полезные ссылки на эту тему.
4 ответа
Это звучит как преждевременная оптимизация. Знаете ли вы, сколько пользователей будет иметь ваш сайт / сколько вычислительных ресурсов будет иметь ваш сервер (ы)? Выберите самый простой (с точки зрения обслуживания) вариант, то есть измените размер на лету, пока производительность не станет проблемой, а затем выясните, что делать.
Это может быть идея реализовать своего рода кэширование на стороне сервера ваших измененных изображений, если они, вероятно, будут неоднократно попадать, но я не думаю, что это должно распространяться до явного предварительного рендеринга.
Это абсолютно несопоставимые вопросы.
Изменение размера изображений на лету фактически похоже на выполнение 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 и этого сайта.
Первые просто не имеют никакой возможности отличить микроскопические вещи от реальных.
Тем не менее, последние не имеют механизма проверки правильности ответов на вопросы - каждый отвечает с одинаковым энтузиазмом, даже если два вопроса противоречат друг другу (и оба имеют здравый смысл).
Динамическое изменение размера может быть дорогостоящей процедурой (в зависимости от времени) в зависимости от начального размера изображений. Я делал это в производственных системах, но когда у меня есть выбор, я решительно предпочитаю кэширование на диск. В конце концов, дисковое пространство дешевое, а время загрузки - это все, что есть в Интернете. Даже если вы просто кэшируете миниатюры с определенным размером и динамически изменяете размеры повсюду, вы можете значительно сократить время загрузки списков изображений в стиле галереи.
Я настоятельно советую вам кэшировать ваши изображения, а НЕ изменять размер на лету.
изменение размера изображений требует значительных ресурсов процессора и памяти вашего сервера.
Если у вас есть галерея изображений, которая будет масштабироваться на лету, страница будет загружать изображения медленно, скажем, около 3-10 секунд, в зависимости от исходного размера файла.
При изменении размера требуется около 3 байтов pr пикселя вашей памяти. Таким образом, если у вас есть размер изображения 1000x1000, это займет около 3 МБ памяти. Если на одной из ваших веб-страниц есть много таких изображений, изменяемых на лету, скажем, 20, это займет около 60 МБ ОЗУ вашего сервера. Возможно нет, так как большинство клиентов запрашивают только 4 изображения за один раз, но 12 МБ все еще много для загрузки страницы. Я бы только масштабировал на лету, если исходное изображение меньше, чем 100x100 пикселей.
СОВЕТ: PhpThumb отлично подходит для масштабирования и сохранения больших пальцев.