Это могло бы быть весомым аргументом, если бы не тот факт, что рядом работают другие и нормальные. Ну у автора статьи может и нет. Но у нас похожая проблема, компания из 100 человек примерно. Хорошо, что таких все таки увольняют, не сразу, после того как накопится критическая масса жалоб и / или косяков, но лучше так, чем никак.
Ошибка выжившего? Я в 2010-ых пробовал фриланс - уже тогда это была помойка («сделай мне полную копию одноклассников за 10000 руб»). А щас типа «навайбкодь полную копию одноклассников за тыщу руб»?
В итоге мясо тут юзеры, которых всякими уловками пытаются убедить купить подписку. И где там тонкая грань между «мы вам честно рассказали о преимуществах» и «купи уже эту чертову ручку»
Кстати, мне где-то попалось, что типа приложения с астрологией и картами таро дают неплохую конверсию.
Это для вас он стал элементарным, в тот момент когда вы об этом узнали. А другим может никогда в голову не приходило вешать транзакцию на вложенный (приватный?) метод и у них все всегда работало.
У меня была подобная фигня однажды на собесе давным-давно. Вопрос был какой-то заковыристый про race condition, deadlock и все такое. У меня уже был некоторый опыт, но я не смог ответить. Потому что когда я строил свое решение (проект как раз был в банковской сфере, но не АБС) - я в первую очередь подумал про конфликты обработки данных, разграничил обработку порциями без пересечений и у меня не было проблем ни на запланированной нагрузке, ни на повышенной спустя некоторое время.
Это как раз те моменты, когда ответ на вопрос «я такой говнокод не пишу».
С другой стороны я лично наталкивался на различную другую дичь, но мне в голову не придет спрашивать про нее.
Например вы знаете, что mysql при определенной комбинации по разному обрабатывает блокировки на таблице с уникальным индексом? И зависит это от того - вызываете вы это внутри хранимки или без нее?
Я так же проверил mssql и postgresql, и там такой фигни нет.
К сожалению нет, мы уже переделали. Раньше можно было пихнуть в джобу массив ид-шников для обработки, но потом отказались и сделали - одна джоба - один ИД, и необходимость в параллельной обработке отпала. Точнее, теперь этим рулит сам хангфайр.
Выглядит слишком сложно для сотни пользователей, saga какая-то появилась. Но это не отменяет того, что все такие операции (связанные с распределением физических благ - деньги и товар) всегда в итоге идут в один поток с блокировками.
Да, можно параллельно отработать со snapshota-ми, но потом они все равно все сойдутся в одной точке, с нормальной полноценной транзакционной блокировкой. В 99% случаев все будет хорошо, но вот на краю в 1% кому-то не достанется.
Так как во время обработки возможны проблемы с сетью, с подключением к БД, деадлоками - нужна retry policy. А это означает - очередь, с асинхронной обработкой, и три статуса для пользователя на UI - In processing | Approved | Failed (после допустим 5 попыток).
Да, я тот момент понял про пул потоков и возврат в исходный, просто тогда это означает то, что пересказывают в интернетах про ConfigureAwait и ASP.NET Core не совсем точная инфа. И вот дальше копать уже особо времени не было.
Интересно, сколько времени заняло все это выяснить?
В чистом веб-сервисе ConfigureAwait(false) ничего не меняет: поведение и так такое. ConfigureAwait(false) нужен в библиотечном коде, который может вызываться из WPF, WinForms или Xamarin, где SynchronizationContext есть. Если вы пишете обычный backend на ASP.NET Core, можно спокойно об этом не думать
И вот тут вот, у меня был кейс где помогло. Я глубоко не раскапывал как так вышло. Aspnet core приложение, Hangfire вызывает джобу, внутри джобы обращение к внешней системе с использованием Linq parallel.
Без этой настройки stop watch внутри каждого вызова показывали приемлемое время в сумме, типа 150-250мс * 10. Но общий stop watch на всю джобу выдавал значительно больше. Будто все висело где-то.
Добавил ConfigureAwait(false) и общий stop watch стал почти совпадать с суммой вложенных, что изначально и ожидалось.
У меня детская травма, связанная с игрой Ну, погоди! Как вижу картинку - сразу ее вспоминаю, каждый раз.
Мне было лет 6, летели в ил-86, в Москву из Ташкента, и там раздавали эти электронные игры по салону, мы сидели после крыльев, папа сказал - иди сбегай, попроси игру, поиграешь, ну я побежал, но не успел.
Это могло бы быть весомым аргументом, если бы не тот факт, что рядом работают другие и нормальные. Ну у автора статьи может и нет. Но у нас похожая проблема, компания из 100 человек примерно. Хорошо, что таких все таки увольняют, не сразу, после того как накопится критическая масса жалоб и / или косяков, но лучше так, чем никак.
Кажется вот они все эти 1000 откликов
Не подсказывайте 🙃 они же все начнут, как под копирку, вставлять именно эту фразу.
И снова тех лид - два в одном с тим лидом, даже три в одном - еще и CTO, мда, а зп сколько?
https://spb.hh.ru/vacancy/133973171
Госпадя, еще и системный/бизнес аналитик. Вы там 30 чел наняли - кто тогда они и что они будут делать??
Ошибка выжившего? Я в 2010-ых пробовал фриланс - уже тогда это была помойка («сделай мне полную копию одноклассников за 10000 руб»). А щас типа «навайбкодь полную копию одноклассников за тыщу руб»?
А в C# точнее в ADO.NET еще есть DBNull
Афигеть! Не знал что там разные типы магнитных слоев. А советские типа мк-60 (у меня только они были) на каком уровне среди этих из статьи?
В итоге мясо тут юзеры, которых всякими уловками пытаются убедить купить подписку. И где там тонкая грань между «мы вам честно рассказали о преимуществах» и «купи уже эту чертову ручку»
Кстати, мне где-то попалось, что типа приложения с астрологией и картами таро дают неплохую конверсию.
Надо еще было наложить график найма новых сотрудников для FAANG-ов.
Это для вас он стал элементарным, в тот момент когда вы об этом узнали. А другим может никогда в голову не приходило вешать транзакцию на вложенный (приватный?) метод и у них все всегда работало.
У меня была подобная фигня однажды на собесе давным-давно. Вопрос был какой-то заковыристый про race condition, deadlock и все такое. У меня уже был некоторый опыт, но я не смог ответить. Потому что когда я строил свое решение (проект как раз был в банковской сфере, но не АБС) - я в первую очередь подумал про конфликты обработки данных, разграничил обработку порциями без пересечений и у меня не было проблем ни на запланированной нагрузке, ни на повышенной спустя некоторое время.
Это как раз те моменты, когда ответ на вопрос «я такой говнокод не пишу».
С другой стороны я лично наталкивался на различную другую дичь, но мне в голову не придет спрашивать про нее.
Например вы знаете, что mysql при определенной комбинации по разному обрабатывает блокировки на таблице с уникальным индексом? И зависит это от того - вызываете вы это внутри хранимки или без нее?
Я так же проверил mssql и postgresql, и там такой фигни нет.
Кстати довольно медленная штука, по крайне мере в MySql
https://habr.com/ru/articles/965812/comments/#comment_29113868
https://habr.com/ru/articles/955714/comments/#comment_28961570
А ему лопаты продает нвидия
К сожалению нет, мы уже переделали. Раньше можно было пихнуть в джобу массив ид-шников для обработки, но потом отказались и сделали - одна джоба - один ИД, и необходимость в параллельной обработке отпала. Точнее, теперь этим рулит сам хангфайр.
Выглядит слишком сложно для сотни пользователей, saga какая-то появилась. Но это не отменяет того, что все такие операции (связанные с распределением физических благ - деньги и товар) всегда в итоге идут в один поток с блокировками.
Да, можно параллельно отработать со snapshota-ми, но потом они все равно все сойдутся в одной точке, с нормальной полноценной транзакционной блокировкой. В 99% случаев все будет хорошо, но вот на краю в 1% кому-то не достанется.
Так как во время обработки возможны проблемы с сетью, с подключением к БД, деадлоками - нужна retry policy. А это означает - очередь, с асинхронной обработкой, и три статуса для пользователя на UI - In processing | Approved | Failed (после допустим 5 попыток).
Если так проверять - то и купить будет нечего 😅
Так, это конверсия собесов в оферы, а какая конверсия откликов в собесы?
Да, я тот момент понял про пул потоков и возврат в исходный, просто тогда это означает то, что пересказывают в интернетах про ConfigureAwait и ASP.NET Core не совсем точная инфа. И вот дальше копать уже особо времени не было.
Интересно, сколько времени заняло все это выяснить?
И вот тут вот, у меня был кейс где помогло. Я глубоко не раскапывал как так вышло. Aspnet core приложение, Hangfire вызывает джобу, внутри джобы обращение к внешней системе с использованием Linq parallel.
Без этой настройки stop watch внутри каждого вызова показывали приемлемое время в сумме, типа 150-250мс * 10. Но общий stop watch на всю джобу выдавал значительно больше. Будто все висело где-то.
Добавил
ConfigureAwait(false)и общий stop watch стал почти совпадать с суммой вложенных, что изначально и ожидалось.Зубы жителя? 😅 /s
У меня детская травма, связанная с игрой Ну, погоди! Как вижу картинку - сразу ее вспоминаю, каждый раз.
Мне было лет 6, летели в ил-86, в Москву из Ташкента, и там раздавали эти электронные игры по салону, мы сидели после крыльев, папа сказал - иди сбегай, попроси игру, поиграешь, ну я побежал, но не успел.
Так и живем 🙃
Че то не очень понятно со string format - заменили на тормознутую конкатенацию, которую исправляли в другом месте и все залетало?