На аплоудах у нас происходит обработка пользовательских картинок, гифок и видео. Контент от пользователей может быть тяжелым — мы не хотим ставить слишком низкие ограничения, чтобы не лишаться части контента/аудитории. Поэтому и обработка единицы контента может потребовать большого количества ресурсов. Обработчики (например, ffmpeg), умеют хорошо утилизировать ядра. Получается, что чем больше ресурсов мы выделяем контейнеру, тем меньше задержка при обработке единицы контента. А значит, мы можем обрабатывать более тяжелые файлы, укладываясь в таймаут.
Слишком большие контейнеры, конечно, тоже не хочется делать, потому что подавляющее большинство файлов все-таки небольшие, так что большая часть ресурсов будет часто простаивать.
Во-первых, есть ограничение на максимальное количество картинок в альбомах пользователя. Во-вторых, есть большая общая антиспам-система, про которую быстро не рассказать. Возможно, про нее тоже в будущем появится статья.
avif не рассматривали. Нам нужно уметь работать с максимальным количеством всевозможных устройств и браузеров. В старых версиях нет поддержки этого формата, так что переход на него может отсечь часть аудитории.
Когда-то использовали классический BerkeleyDB, потом решили написать свое. Тут было про причины: https://www.youtube.com/watch?v=uuGbbJhS7o8 . Как минимум, хотелось хранить максимально компактно, так как данных очень много. При этом, не жертвовать надежностью. Например, для холодных данных у нашего стораджа фактор репликации равен 2.1 при возможности потерять 1 из 3 дц + часть реплик из оставшихся двух. На момент написания, подобных решений не было, насколько я понимаю.
>даже с более быстрым libvips
Если вы где-то видели сравнение производительности IPP и libvips, мне было бы интересно посмотреть.
>10мб в 500кб
В момент аплоада мы сжимаем картинки, так что они у нас изначально весят не 10 МБ, а на 1-2 порядка меньше.
>занимает примерно 2-3 секунды.
Но все равно в некоторых, редких случаях, трансформация может занять много времени (единицы секунд). В этом случае пользователь действительно будет ждать картинку столько времени. Но только в первый раз. Дальше она попадет в кеш и довольно долго там будет оставаться.
50-300 кБ — это много в случаях, когда мы можем обойтись всего 1-2 кБ. Но все равно, если у вас есть источник, где сравнивается качество выходных картинок libvips и IPP (или других библиотек), я бы глянул.
У вас меняется дизайн. Картинки теперь нужно делать на 200px по ширине больше. Что делать ? Ведь у вас случится обвал, нагрузка на пережатие кратно увеличится.
Чтобы не было перегрузки, подобные изменения включаются поэтапно. Сначала выкладываем на 0.5% пользователей, и дальше по нарастающей. После первой итерации кеш начнет заполняться новыми размерами, что позволит безопасно добавить еще часть аудитории. Между итерациями следим за графиками/логами, в случае проблем откатываем изменение.
Но, конечно, совсем без роста нагрузки тут не обойдется. Пока новый дизайн не раскатится полностью, в кеше будут лежать и старые, и новые версии картинок. То есть его эффективная емкость уменьшится, будет больше кеш миссов и больше нагрузка на трансформеры. Поэтому мы выделяем нашим сервисам железа с запасом (ориентируемся примерно на x2 от потребления в час пик).
Как выбиралось дефолтное качество энкодера, мне казалось, что в ок все фото всегда сильно пожаты.
Фотки жмем, да. Чтобы сильно быстро не заполнялся сторадж. На это и ориентируемся при выборе качества. Обращения пользователей тоже влияют. Например, в 2023 мы подняли максимальное разрешение картинок с 1680x1680 до 2560x2560.
Новый процесс действительно дороговато создавать. Но у нас процессы IPP долгоживущие, для запуска трансформации нужно просто передать команду в stdin.
По поводу джавы. Сейчас делают крутые штуки для улучшения производителности в рамках проектов Panama и Valhalla. Только не знаю, насколько они уже заадопчены в либы, работающие с картинками. Ну и сами проекты еще не закончены. Но в перспективе будет интересно посравнивать перфоманс.
Все нормально, вполне адекватный вопрос :)
На аплоудах у нас происходит обработка пользовательских картинок, гифок и видео. Контент от пользователей может быть тяжелым — мы не хотим ставить слишком низкие ограничения, чтобы не лишаться части контента/аудитории. Поэтому и обработка единицы контента может потребовать большого количества ресурсов. Обработчики (например, ffmpeg), умеют хорошо утилизировать ядра. Получается, что чем больше ресурсов мы выделяем контейнеру, тем меньше задержка при обработке единицы контента. А значит, мы можем обрабатывать более тяжелые файлы, укладываясь в таймаут.
Слишком большие контейнеры, конечно, тоже не хочется делать, потому что подавляющее большинство файлов все-таки небольшие, так что большая часть ресурсов будет часто простаивать.
Во-первых, есть ограничение на максимальное количество картинок в альбомах пользователя. Во-вторых, есть большая общая антиспам-система, про которую быстро не рассказать. Возможно, про нее тоже в будущем появится статья.
avif не рассматривали. Нам нужно уметь работать с максимальным количеством всевозможных устройств и браузеров. В старых версиях нет поддержки этого формата, так что переход на него может отсечь часть аудитории.
Когда-то использовали классический BerkeleyDB, потом решили написать свое. Тут было про причины: https://www.youtube.com/watch?v=uuGbbJhS7o8 . Как минимум, хотелось хранить максимально компактно, так как данных очень много. При этом, не жертвовать надежностью. Например, для холодных данных у нашего стораджа фактор репликации равен 2.1 при возможности потерять 1 из 3 дц + часть реплик из оставшихся двух. На момент написания, подобных решений не было, насколько я понимаю.
>даже с более быстрым libvips
Если вы где-то видели сравнение производительности IPP и libvips, мне было бы интересно посмотреть.
>10мб в 500кб
В момент аплоада мы сжимаем картинки, так что они у нас изначально весят не 10 МБ, а на 1-2 порядка меньше.
>занимает примерно 2-3 секунды.
Но все равно в некоторых, редких случаях, трансформация может занять много времени (единицы секунд). В этом случае пользователь действительно будет ждать картинку столько времени. Но только в первый раз. Дальше она попадет в кеш и довольно долго там будет оставаться.
50-300 кБ — это много в случаях, когда мы можем обойтись всего 1-2 кБ. Но все равно, если у вас есть источник, где сравнивается качество выходных картинок libvips и IPP (или других библиотек), я бы глянул.
Чтобы не было перегрузки, подобные изменения включаются поэтапно. Сначала выкладываем на 0.5% пользователей, и дальше по нарастающей. После первой итерации кеш начнет заполняться новыми размерами, что позволит безопасно добавить еще часть аудитории. Между итерациями следим за графиками/логами, в случае проблем откатываем изменение.
Но, конечно, совсем без роста нагрузки тут не обойдется. Пока новый дизайн не раскатится полностью, в кеше будут лежать и старые, и новые версии картинок. То есть его эффективная емкость уменьшится, будет больше кеш миссов и больше нагрузка на трансформеры. Поэтому мы выделяем нашим сервисам железа с запасом (ориентируемся примерно на x2 от потребления в час пик).
Фотки жмем, да. Чтобы сильно быстро не заполнялся сторадж. На это и ориентируемся при выборе качества. Обращения пользователей тоже влияют. Например, в 2023 мы подняли максимальное разрешение картинок с 1680x1680 до 2560x2560.
Новый процесс действительно дороговато создавать. Но у нас процессы IPP долгоживущие, для запуска трансформации нужно просто передать команду в stdin.
По поводу джавы. Сейчас делают крутые штуки для улучшения производителности в рамках проектов Panama и Valhalla. Только не знаю, насколько они уже заадопчены в либы, работающие с картинками. Ну и сами проекты еще не закончены. Но в перспективе будет интересно посравнивать перфоманс.