Судя по страничке Speed-and-memory-use libvips быстрее, но должен заметитить, что результаты imlib2 у них конечно немного странные и возможно они что то не докрутили. Более существенный, по моему мнению, недостаток imlib2- странная лицензия и достаточно маленькое комьюнити. Хотя погонять бенчмарк возможно все таки стоит.)
Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд.
Nginx кэширует ответы бэкенда, и при следующем запросе она отдается уже из кэша, а не с бэкенда. В readme в репе есть пример конфига Nginx, который реализует эту логику.
По поводу ресайза в несколько проходов. Не могли бы Вы рассказать как вы это делали и какой библиотекой? На первый взгляд похоже на проблему с алгоритмом ресайза, из-за которой он при большом изменении размера портил качество. Теоретически вариант, когда мы ресайзим большую в маленькую должен быть лучше, чем вариант, когда мы делаем «большая->средняя->маленькая», т.к. не происходит потери на шаге «большая->средняя».
Естественно, мы так и делаем. В моем коде это работает так:
Вместо "/test.png" в том месте страницы, где нужна маленькая версия мы пишем "/test.png@75". Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд. Он в свою очередь пасит url, скачивает оригинал ("/test.png"), ресайзит его до нужного разрешения и отдает nginx'у. Nginx кэширует результат и отдает его клиенту.
Не очень понял, что вы имеете в виду под простым случаем. Часть информации мы при ресайзе естественно теряем, но это не должно ухудшать качество картинки «на глаз»(естественно если потом получившуюся картинку не растягивать до размера оригинала).
Если же это проявляется в заметных артефакт, то есть смысл смотреть на алгоритм ресайза и его настройки.
На всякий случай уточню предыдущий коммент: мы храним только оригиналы в максимальном используемом разрешении (200х200 в примере). Менее качественные версии генерируются динамически и только кешируются на некоторое время.
Второй момент: например про главную. 75х75 это размер, определяемый версткой страницы, то есть в верстке есть контейнер 75х75 пикселей и мы вставляем туда версию нужного размера. Мы естественно не вставляем 75 версию в 200 контейнер.
Немного не наш кейс, у нас это работает например для таких случаев: аватарка пользователя хранится и показывается в профиле в 200х200, но на страницах форума показывается в 150х150, а например на главной в 75х75. И все эти уменьшенные версии надо генерить автоматом. Кроп, кадрирование и прочие фичи там не нужны.
Мы естественно тоже кешируем результаты nginx'ом, но бывают например, что приходит какой то трафик на старые страницы, для которых кэша нет или сбросился кэш. Отсюда интерес к производительности без кеша.
Чем нам не понравилось решение на nginx- накрутить нашу логику в конфиге можно, но выглядеть это будет очень уж страшно. Новых проектов это конечно не касается, там больше свободы и можно и на nginx сделать красиво.
Libvips дает возможность конвертировать картинки между разными форматами, в том числе в webp, но мы пока ей не пользуемся. За наводку спасибо, возможно стоит конвертировать в webp.
Спасибо, действительно не самый удачный пример и на некоторых картинках пережатие работает не очень хорошо. Добавил пример хорошей картинки и немного поменял описание.
Так я как раз и говорю о том, что для использования в вебе желательно не только ресайзить изображения, но и пережимать, потому что это может существенно сократить размер картинки. В своем решении мы совмещаем ресайз и пережатие, потому что только ресайз выдает достаточно большие по объему изображения.
Во первых да, примеры для статьи я пережимал с качеством 80, т.к. оно дает хорошее соотношение качество/объем. Естественно можно использовать более высокие настройки качества.
Во вторых артефакты, о которых вы говорите, я заметил только при 500% увеличении картинки в браузере, но ее увеличение не предполагается.
Видел информацию о том, что разработчики FreeBSD получили инфу вовремя, а с Тео произошла забавная история. Когда нашли баг в WPA2 ему сообщили о уязвимости наряду со всеми, но он раскрыл инфу о ней широкой общественности до оговоренной даты релиза. После этого случая ему сказали, что будут сообщать ему о таких уязвимостях в последний момент. Снятие эмбарго на мелтдаун планировалось на 9 января и вероятно ему бы сообщили детали уязвимости 6-7 января, но инфу разболтали раньше времени.
Замечу, что человек выше не говорил, что внешнее пространство необходимо для объяснения наблюдений, а лишь указал, что объяснение из статьи ему не понятно.
Нашли уже после того, как выкатили сайт через CDN (и он пока продолжает так работать, т.к. данная проблема не затрагивает браузеры), но до включения CDN для REST API (оно работает на отдельном домене).
Да, у нас есть своя специфика. Во первых сайт довольно легкий, страница весит около 500 кб, то есть она грузится достаточно быстро и дополнительный tcp+ssl хендшейк на отдельный домен тратит больше времени, чем выигрывает. Особенно если клиент в US или Австралии (сервера у нас в Европе). А если соединение по HTTP/2, то разница еще заметнее.
К сожалению не получится. Когда подключали cdn проводили тестирование скорости и получился следующий топ (от самого быстрого к медленному, замеряли время dom ready на клиентах):
1) Статика на основном домене через CDN
2) Статика на основном домене без CDN
3) Статика на отдельном домене через CDN
4) Статика на отдельном домене без CDN
То есть использовать CDN есть смысл только в 1 случае, когда через cdn проксируется весь трафик сайта, а статика лежит на том же домене. Работать в таком режиме без POST запросов естественно нельзя. Вообще тема достаточно большая и если интересно могу написать отдельную статью о том, как мы это замеряли и к каким выводам пришли. ;)
Ну это всего лишь тестовый скрипт. В Android приложении, как я понимаю дело было в том, что программисты отправляли в http клиент данные через stream buffer, а он отправлял данные чанками по мере получения.
он для случаев, когда на стороне источника потока данных есть какая-то относительно сложная логика, данных много и заранее неизвестно, когда они закончатся.
Да, и это не обязательно должен быть сервер, это может быть и клиент. И в спецификации HTTP сказано, что этот функционал должен быть реализован.
Nginx кэширует ответы бэкенда, и при следующем запросе она отдается уже из кэша, а не с бэкенда. В readme в репе есть пример конфига Nginx, который реализует эту логику.
По поводу ресайза в несколько проходов. Не могли бы Вы рассказать как вы это делали и какой библиотекой? На первый взгляд похоже на проблему с алгоритмом ресайза, из-за которой он при большом изменении размера портил качество. Теоретически вариант, когда мы ресайзим большую в маленькую должен быть лучше, чем вариант, когда мы делаем «большая->средняя->маленькая», т.к. не происходит потери на шаге «большая->средняя».
Вместо "/test.png" в том месте страницы, где нужна маленькая версия мы пишем "/test.png@75". Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд. Он в свою очередь пасит url, скачивает оригинал ("/test.png"), ресайзит его до нужного разрешения и отдает nginx'у. Nginx кэширует результат и отдает его клиенту.
Если же это проявляется в заметных артефакт, то есть смысл смотреть на алгоритм ресайза и его настройки.
На всякий случай уточню предыдущий коммент: мы храним только оригиналы в максимальном используемом разрешении (200х200 в примере). Менее качественные версии генерируются динамически и только кешируются на некоторое время.
Второй момент: например про главную. 75х75 это размер, определяемый версткой страницы, то есть в верстке есть контейнер 75х75 пикселей и мы вставляем туда версию нужного размера. Мы естественно не вставляем 75 версию в 200 контейнер.
Чем нам не понравилось решение на nginx- накрутить нашу логику в конфиге можно, но выглядеть это будет очень уж страшно. Новых проектов это конечно не касается, там больше свободы и можно и на nginx сделать красиво.
Во вторых артефакты, о которых вы говорите, я заметил только при 500% увеличении картинки в браузере, но ее увеличение не предполагается.
Видел информацию о том, что разработчики FreeBSD получили инфу вовремя, а с Тео произошла забавная история. Когда нашли баг в WPA2 ему сообщили о уязвимости наряду со всеми, но он раскрыл инфу о ней широкой общественности до оговоренной даты релиза. После этого случая ему сказали, что будут сообщать ему о таких уязвимостях в последний момент. Снятие эмбарго на мелтдаун планировалось на 9 января и вероятно ему бы сообщили детали уязвимости 6-7 января, но инфу разболтали раньше времени.
— Скольких каналов?
— Четырех.
1) Статика на основном домене через CDN
2) Статика на основном домене без CDN
3) Статика на отдельном домене через CDN
4) Статика на отдельном домене без CDN
То есть использовать CDN есть смысл только в 1 случае, когда через cdn проксируется весь трафик сайта, а статика лежит на том же домене. Работать в таком режиме без POST запросов естественно нельзя. Вообще тема достаточно большая и если интересно могу написать отдельную статью о том, как мы это замеряли и к каким выводам пришли. ;)
Да, и это не обязательно должен быть сервер, это может быть и клиент. И в спецификации HTTP сказано, что этот функционал должен быть реализован.