Я создаю сайт для обмена изображениями и хотел бы знать плюсы и минусы изменения размеров изображений на лету с помощью PHP и сохранения сохраненных изображений.
Что быстрее?
Что более надежно?
Насколько велика разница между двумя методами в скорости и производительности?
Обратите внимание, что в любом случае изображения проходят через PHP-скрипт для статистики, такой как представления или если хотлинкинг разрешен и т. Д. … так что это не так, потому что это будет прямая ссылка для изображений, если я захочу сохранить изображения с изменением размера.
Я буду оценивать ваши комментарии или любые полезные ссылки на эту тему.
Это звучит как преждевременная оптимизация. Знаете ли вы, сколько пользователей вашего сайта будет иметь / сколько вычислительных ресурсов хватит на ваших серверах? Пойдите с самым простым (поддерживающим) вариантом, то есть измените размер на лету, пока производительность не станет проблемой, а затем выясните, что делать.
Может быть, идея реализовать какое-то кеширование на стороне сервера ваших изображений с масштабированием, если они, вероятно, будут многократно ударяться, но я не думаю, что это необходимо расширить до явного предварительного рендеринга.
Это абсолютно несравнимые дела.
Фактически, изменение размера изображений на лету похоже на запуск 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 000!) С общей суммой 100 МБ. Хотя обычный предел памяти для скрипта PHP составляет всего 8 М, и это редко достигается.
Это реальные цифры жизни.
Несколько смешная вещь, связанная с этой проблемой:
Точно тот же пользователь PHP, который легко отбрасывает 1000000 циклов процессора, в то же время невероятно ревнив, чтобы сэкономить 1 или 2! Это не фигура речи, вот пример того, о чем я говорю:
Аналогичный вопрос у кого-то, чья серьезная озабоченность в то же время ничтожно мала, как разница в скорости между константами, переменными или переменными массивами . И кто недавно столкнулся с разрешенной памятью, исчерпала проблему , как будто такого бедствия было недостаточно.
Есть TONS вопросов и ответов на этом сайте, обсуждая наносекундную разницу в скорости любых операций, отвечающих неисчерпаемым достоинством, проверяя миллионы итераций, чтобы показать абсолютно ничтожную разницу между однократными операциями нескольких циклов ЦП каждый.
И в то же время есть такие вопросы – относительно огромной, несравненной разницы в показателях производительности между двумя подходами, которая выглядит просто равной автору.
Это проблема со средним пользователем PHP и этим сайтом.
У первых просто нет никакой возможности сказать реальные вещи из микроскопических.
Но у последних нет механизма проверки здравомыслия по вопросам – каждый ответил с равным энтузиазмом, даже если два вопроса противоречат друг другу (и оба имеют здравый смысл).
Динамическое изменение размера может быть дорогостоящей процедурой (по времени) в зависимости от исходного размера изображений. Я сделал это в производственных системах, но когда у меня есть выбор, я решительно рекомендую кэширование на диск. В конце концов, дисковое пространство дешево, а время загрузки – все в Интернете. Даже если вы просто кешируете эскизы определенного размера и выполняете динамическое изменение размеров везде, вы можете значительно сократить время загрузки для списков изображений в стиле галереи.
Я настоятельно рекомендую вам кэшировать ваши изображения и НЕ изменять размер на лету.
изменение размера изображений очень интенсивно для процессора и использования памяти для вашего сервера.
Если у вас есть галерея изображений, которая будет масштабироваться «на лету», страница будет медленно загружать изображения, скажем, что-то вроде 3-10 секунд, зависит от исходного размера файла.
При изменении размера занимает около 3 байтов pr-пикселя вашей памяти. Итак, если у вас есть изображение размером 1000×1000 для изменения размера, это займет около 3 МБ памяти. Если на одном из ваших веб-страниц есть много изображений с изменением размера на лету, скажем, 20, это займет около 60 МБ ОЗУ вашего сервера. Возможно, нет, так как большинство клиентов запрашивают только 4 изображения в то время, но 12 МБ по-прежнему много для pageload. Я бы только масштабировал на лету, если исходное изображение меньше 100×100 px.
СОВЕТ. Отличная библиотека для масштабирования и сохранения больших пальцев – PhpThumb