Какие бенчи ты хочешь увидеть?

если ресайз jpeg должен пройти с компрессией в 95%, а png 5%, да и при этом вотермарк для каждой обратившейся страны должен быть разный (локализация) - то уже переходит в разряд оной.

а так конечно надо смотреть конкретную задачу

выше были слова что приложение на пхп которое делает ресайз медленнее чем решение на нгинксе

я хотел в бенче увидеть что они делают логику 1 в 1, без упрощений

ну и время обработки)

просто раз тут хабр затронули как место для вот таких статей типа "не видел на хабре - херня", то стоит наверное глянуть на любую статью где что-то пытаются сравнивать и внезапно выясняется что более медленное решение или написано было херово или просто на 95% делает легаси-логику которую в более быстром выкинули

это нормально и обычно это даже не скрывают, говоря что перешли на сервис на  go просто пересмотрев бизнес-логику и упростив ее

но аппелировать этим потом в спорах говоря что вот оно - решение универсальное - глупо

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

Есть ли возможность каким-то адекватным образом побороть UDP через докер под виндой, проблема така что из контенера рассылается броадкаст, судя по шарку он проходит, и клиенты отправляют ответ .. но ответ до контейнера не доходит, стоит net=host. Как можно поправить?

Товарищ синьор пхп девелопер дело говорит ! х)))

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

что значит в "контейнере" ?

ок.

давай я скажу что переписал сервис с php на go, это избавило меня от необходимости хранения ресайзов, приложения на лету определяют какого размера нужна картинка - по сути решив те же самые проблемы о которых ты написал и тоже выиграв в скорости?

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

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

это оффтоп, спор на этом наверное закончу. спасибо)

Не за что;) обращайтесь, у нас тут много интересных решений

а у нас это где?

Кто то говорит, а кто то делает и имеет готовые решения в виде docker-compose, могу даже поделиться, мне не жалко