Комментарии 9
А почему возможности Java для трансформации картинок не используются?
Тут хайлоад, нужно максимально оптимизированные библиотеки типа libvips желательно использующие simd инструкции.
Тут вопрос в том, что более эффективно - создать новый процесс и обработать быстро, или обработать в том же потоке но чуть медленнее
это должна решать os. Не вижу проблем с потоками, забирает свободный.
Новый процесс действительно дороговато создавать. Но у нас процессы IPP долгоживущие, для запуска трансформации нужно просто передать команду в stdin.
По поводу джавы. Сейчас делают крутые штуки для улучшения производителности в рамках проектов Panama и Valhalla. Только не знаю, насколько они уже заадопчены в либы, работающие с картинками. Ну и сами проекты еще не закончены. Но в перспективе будет интересно посравнивать перфоманс.
Вопрос.
У вас меняется дизайн. Картинки теперь нужно делать на 200px по ширине больше. Что делать ? Ведь у вас случится обвал, нагрузка на пережатие кратно увеличится.
И второй вопрос. Как выбиралось дефолтное качество энкодера, мне казалось, что в ок все фото всегда сильно пожаты.
У вас меняется дизайн. Картинки теперь нужно делать на 200px по ширине больше. Что делать ? Ведь у вас случится обвал, нагрузка на пережатие кратно увеличится.
Чтобы не было перегрузки, подобные изменения включаются поэтапно. Сначала выкладываем на 0.5% пользователей, и дальше по нарастающей. После первой итерации кеш начнет заполняться новыми размерами, что позволит безопасно добавить еще часть аудитории. Между итерациями следим за графиками/логами, в случае проблем откатываем изменение.
Но, конечно, совсем без роста нагрузки тут не обойдется. Пока новый дизайн не раскатится полностью, в кеше будут лежать и старые, и новые версии картинок. То есть его эффективная емкость уменьшится, будет больше кеш миссов и больше нагрузка на трансформеры. Поэтому мы выделяем нашим сервисам железа с запасом (ориентируемся примерно на x2 от потребления в час пик).
Как выбиралось дефолтное качество энкодера, мне казалось, что в ок все фото всегда сильно пожаты.
Фотки жмем, да. Чтобы сильно быстро не заполнялся сторадж. На это и ориентируемся при выборе качества. Обращения пользователей тоже влияют. Например, в 2023 мы подняли максимальное разрешение картинок с 1680x1680 до 2560x2560.
1) В какой момент и как вы ограничивается от флудеров? По вашей тайлапс схеме как бы и не видно в какой момент происходит чек ограничений по досу.
1.1) Как вы отделсяется флудера от обычного челвоека который заливает огромный альбом?
2) По схеме вы всегда возвращается как я понял урл с расширением, тоесть вы не используете подход конвертации всех типов картинок в avif допустим?
3) почему вы не используете классические seaweedfs или подобные ? Где как бы есть с подключением новых хранилищ в 1 клик и их перераспределением по десятку параметров.
4) дальше у меня не сходится ваш FLOW IO, с реальностью даже с более быстрым libvips, где 1 картинка в 10мб в 500кб занимает примерно 2-3 секунды.
5) в чём вообще смысл 10тка разных разрешений если современный libvips выдаст вам практически того же качества в 50-300кб сайче что делает абсолютно бесмысленны thumbnailes
Во-первых, есть ограничение на максимальное количество картинок в альбомах пользователя. Во-вторых, есть большая общая антиспам-система, про которую быстро не рассказать. Возможно, про нее тоже в будущем появится статья.
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 (или других библиотек), я бы глянул.
Смотрим «под капот» бэкенда изображений в ОК