У кого-то возникала необходимость писать многопоточный код на бэкенде (явная

работа с тредами или plinq)?
Есть конкретные юзкейсы, где это может пригодиться на бэке и оно не решаемо путем скейлинга инстансов?

А можно немного больше подробностей про скейлинг инстансов?

Ну я исхожу из позиции что серверное asp.net приложение в реальных боевых условиях загружено на 100% и выиграть в производительности от многопоточного кода там не получиться. Решать это проблему стоит архитектурно путем масштабирования самих инстансов. Но интервьюверы гоняют по тредам и плинку на бэкенд...

Дуже багато кейсів, я думаю це прям повсюдно зустрічається в коді Зараз з тредами не дуже багато працюють, більше з тасками. Plinq також не супер часто зустрічається. Але коли у тебе є N елементів, які в конкретному місці коду потрібно розпаралелити, ти можеш обрати будь-який варіант із доступних. Хоча зараз основну функціональність по розпаралелюванню надають фреймворки (e.g. ASP.NET Core) / рантайм (e.g. Azure Functions) із коробки, в залежності від того що і як ти використовуєш. Ти з цим напряму не взаємодієш

Тобто в рамках обробки asp.net екшону паралелити код вже не має сенсу?

Залежить, від задачі, та підходу, який ти використовуєш

CPU-bound код*

В більшості випадків так Навіть сервіси, зареєстровані як transient / scoped, будуть повторно створені для кожного контролера, що дозволяє, наприклад, паралельно звертатися до БД Потенційно ти можеш знизити перформанс паралельного виконання за рахунок неправильно написаного коду, але тут вже конкретні кейси треба дивитися Ти для перевірки можеш написати просте web api та запустити якийсь NBomber, побачиш перформанс паралельного виконання твоєї апки

Я просто не понимаю что подразумевается под "скейлингом инстансов". Нужен пример.

Запустить два-три+ инстансов того же приложения для обработки запросов

Работа с лоад балансерами в смысле?

да

Это выбор того, кто платит за хостинг вычислительных мощностей.

У меня недавно была дискуссия и я хочу поднять её тут, если уже зашла тема. Что важнее - наращивание вычислительных мощностей при финансовых возможностях или качественная оптимизация кода, выливающаяся в те же расходы на более компетентных разработчиков?

залізо надійніше за людину 😁, не факт, що розраби не замутять фігні

і можна дуже швидко і прогнозовано масштабувати в такий спосіб

Serhii

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

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

Паралельне масштабування якщо правильно назвати

Serhii

інспектор 2006 ))

Я не техлид, но своего рода пидорас

Это мы уже все давно поняли, мог бы не повторять.

Треба завжди уточняти. Бо ця програмістська абстракція вже у печінках

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

Слава 2.0

Важке питання. На нього у мене іюіорвіді немає

Ще 1 спрінт й у відпустку!!!!

Нормально, там не так важко можна самому поекспериментувати і почати інтервьюверів ганяти у відповідь) Головне не юзати Dataflow