EventSource в HTTP, AOT в Яндексе, Locking в EF

[@KislyEmb]

Я человек простой, вижу выпуск ставлю лайк

[@redkostia]

150 миллисекунд хододный старт это сказка просто. 7 лет назад aws поднимался намноооого дольше)

[@tt0nix]

За 7 лет индустрия и требования сильно поменялись. Но да, цифры уже довольно конкурентноспособные. И это не предел, это только начало.

[@redkostia]

@tt0nix да тогда секунды 2-3 точно был холодный старт aws лямбды. Что собственно делало невозможным её использование для http запрос/ответ. Только крон на ней гонял. Помню ещё так и не смог там async/await заюзать. Мне говорил коллега - сделай доклад про лямбду, а мне стыдно стало, что я там .GetAwaiter().GetResult() вызываю 🤣 и постеснялся 😂

[@redkostia]

@tt0nix да тогда точно секунды 2-3 был холодный старт у aws лямбды. Для веба юзать нельзя было. Только крон на ней гонял.

[@VoroninPavel]

Интересно бы еще сравнить просто AOT и R2R. Если функция относительно долгоиграющая с большим числом циклов, то оптимизация JIT'а может перекрыть потери на (до/пере)компиляцию и загрузку бОльших бинарей в память. Спрашивал у ребят из команды .НЕТ, не хотят ли они сделать возможность сохранять результат работы JIT+PGO, чтоб можно было это использовать на следующих запусках. Ибо для функций и контейнеров было бы самое оно. Но увы, они это обсуждали, но решили не заморачиваться. =(

[@tt0nix]

AOT гораздо быстрее стартует чем R2R. Ну а то что он проигрывает прогретому JIT'у и так видно. Поэтому особого смысла сравнивать нет.

[@bananasba]

MVCC это тот же оптимистик лок (и не факт что блокировки не используются совместно, в SQL Server есть и то и другое). CRDT это больше про eventual consistency и распределенные системы, мол данные записанные в разные реплики сойдутся. Каким-то подходом могут быть например акторы, но они фактически делают доступ к ячейке последовательным, что эквивалентно локу, но сделано за нас. Раньше в EF вообще нельзя было нормально заретраить, счас вроде как можно, но нет желания связываться, 100% они где-то косякнули)

[@tt0nix]

В общем задача решается одинаковая: предсказуемая работа с конкурентным изменением одной области памяти. MVCC это не лок, это версионирование данных. CRDT не обязательно eventual consistency, и уж точно не обязательно распределённые системы. Это больше про математические алгоритмы, как свести результат concurrent вычислений гарантированно без конфликтов (например из многих потоков на одной машине). Акторы это обычная очередь, да очередь это тоже стратегия борьбы с конкурентными изменениями.

[@VoroninPavel]

Э не, при Optimistic Concurrency в худшем случае не ретрай, а merge conflict - что далеко не всегда тривиальная задача на стороне UI - не показывать же пользователю diff. Azure DevOps не заморачивается: можно написать простыню в тикете, а при нажатии на Save получить: "Извиняй, кто-то тикет уже поменял. Обнови все и заново отредактируй." UX, который мы заслужили.

[@tt0nix]

В худшем, да, merge conflict.

[@VoroninPavel]

Один минус у concurrency token'ов в EF - они работают всегда. Нет возможности при SaveChanges сказать: "Вот эти энтити в этот раз на конкурентный доступ не проверяй."

[@tt0nix]

Интересное требование. Надо покопаться в интерсепторах, может можно что-то через них настроить.

[@bananasba]

Вроде же есть pgo?

[@tt0nix]

Да, есть.