Загрузить изображения разных размеров или один размер для последующей обработки? - PullRequest
3 голосов
/ 19 октября 2011

Мой сайт позволяет пользователям загружать изображения профиля, которые затем представлены в нескольких (около 3 или 4) разных размерах вокруг сайта.

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

Как такой сайт, как Facebook или Twitter, справляется с этим? Они обрабатывают изображение разных размеров прямо во время загрузки или хранят изображения более высокого качества и обрабатывают их на стороне сервера при необходимости?

Есть ли общий способ справиться с этим?

Ответы [ 4 ]

4 голосов
/ 19 октября 2011

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

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

Приложение для больших нагрузок

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

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

Независимо от того, что вы делаете, не восстанавливайте альтернативные размеры изображений каждый раз, когда они вам нужны. Храните их где-нибудь.

2 голосов
/ 19 октября 2011

Они обрабатывают изображение разных размеров прямо во время загрузки.

Загрузка происходит один раз, просмотр может происходить тысячи раз. Обработка при загрузке сокращает работу сервера.

1 голос
/ 28 декабря 2012

Если вы хотите получить лучший результат:

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

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

0 голосов
/ 31 декабря 2012

Мои предложения:

Установите ограничения на размер файла, разрешение и формат загрузки и сохраните исходное изображение.

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

К миниатюрам (предположительно) обращаются чаще всего, и они (предположительно) самые маленькие, поэтому имеет смысл хранить их. Хранить изображение, скажем, 1/5 (или меньше) от размера оригинала, вряд ли существенно. Они могут быть сохранены при загрузке.

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

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

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

ImageIO - неплохой, но достаточно простой API обработки изображений. Не уверен, что он может изменить размер. Я вижу, что он имеет некоторые функции кэширования.

...