Блог

Я работаю над CMS и пытаюсь выяснить обычную практику выполнения запроса изображения в стиле REST. У меня есть три размера: маленький, средний и полный. Я думаю сохранить только полное изображение и написать функцию, которая будет изменять размер при каждом запросе страницы. Это приводит к очевидным затратам процессора. С другой стороны, я мог бы сохранить все три размера и вычислять только при загрузке, это, похоже, пустая трата места.

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

Примечание: Я понимаю, что мне не нужно слишком беспокоиться, поскольку это интрасеть, и любое решение будет работать, просто интересно, какое из них было бы предпочтительнее для ознакомления.

Другой вариант — поддерживать кэш изображений с измененными размерами. Предоставьте те, которые доступны. Создайте новые, если они недоступны. Удалите изображения, которые некоторое время не запрашивались.

Это будет компромисс между проблемами процессора и хранилища.

Сохранить полное, затем сгенерировать другие размеры по мере необходимости и кэшировать их; обработка страницы будет немного замедлена при первом запросе, но тогда кэшированная версия будет использоваться для всех последующих запросов.

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

Если вы хотите пофантазировать, вы могли бы настроить кэш MRU (самого последнего используемого) из n наиболее часто запрашиваемых изображений с измененным размером, но опять же, при малом количестве запросов это, вероятно, было бы излишеством — но все равно это мог бы быть интересный проект ! 😉

Одним из ключевых моментов REST и использования по сравнению со стандартными HTTP-глаголами является то, что он поддерживает кэширование; Я думаю, это поддержало бы намерение выполнять динамическое изменение размера. Однако на самом деле это вопрос компромисса между объемом памяти и вычислением во время запроса.

Если загрузка системы не является проблемой (при условии, что приложение для интрасети небольшого объема) Я бы предпочел сохранить изображение в натуральную величину и масштабировать его во время выполнения. Таким образом, если вам когда-нибудь понадобятся другие размеры, вам не нужно будет заменять все ваши изображения.

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

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