VG
Size: a a a
2021 January 19
VG
пс стрим топ
VG
Какую годноту завезли. Спецэффекты так себе, то актеры хорошие - должно быть весело!
VG
Трейлер фильма "День курка", который в оригинале называется Boss level.
Каждый день бывший спецназовец Рой Палвер начинает, отбиваясь от всевозможных убийц: здоровяка с мачете, пулемётчика на вертолёте, двух красоток на быстром авто, виртуозно владеющей мечом китаянки, карлика-подрывника и прочих психопатов. И каждый раз Рой неизменно погибает и снова оказывается в том же дне. Однажды он узнаёт, что его бывшая девушка, которая занималась секретными разработками, мертва. Рой решает докопаться до причин её смерти, а заодно выяснить, как ему самому выбраться из этой невыносимой временной петли.
Каждый день бывший спецназовец Рой Палвер начинает, отбиваясь от всевозможных убийц: здоровяка с мачете, пулемётчика на вертолёте, двух красоток на быстром авто, виртуозно владеющей мечом китаянки, карлика-подрывника и прочих психопатов. И каждый раз Рой неизменно погибает и снова оказывается в том же дне. Однажды он узнаёт, что его бывшая девушка, которая занималась секретными разработками, мертва. Рой решает докопаться до причин её смерти, а заодно выяснить, как ему самому выбраться из этой невыносимой временной петли.
VG
Это очень смешно
VG
пс стрим топ
Мне кста что-то сломали 1 раньше был стрим 4к, щас только 1440p max
D
Мне кста что-то сломали 1 раньше был стрим 4к, щас только 1440p max
я в 2к смотрел всегда, не заметил
VG
я в 2к смотрел всегда, не заметил
А люди в основном в 1080р смотрят.
AR
Мне кста что-то сломали 1 раньше был стрим 4к, щас только 1440p max
это youtube, детка
VG
это youtube, детка
Не, мне сломали мои же эксперты - пароли от YT мне не дают, с stream key создали на 1440р
AR
увольняй таких
VG
Пффф
Контора стала большой, маркетинг тоже
VG
увольняй таких
Growth pains говорят, но раньше это называлось безалаберность
IT
Как не уронить свой сервис под нагрузкой, на примере Signal.
Люди массово переходят из вацапа в Signal. Серверы Signal не выдержали и совсем лежали почти 14 часов, а испытывали серьезные трудности больше суток. Не лучшее время, чтобы падать :( Официальный твиттер сигнала при этом хранил молчание, будто это не модный стартап, а какая-то древняя корпорация. Жаль. Надеюсь, позже они опубликуют подробный разбор, что случилось.
Пока поделюсь, как мы однажды сами положили свои серверы и как от этого защищаемся теперь. Почти все мобильные приложения отправляют запросы на сервер, например, для оформления заказа или отправки сообщения. Важно, как себя ведут мобильные приложения, если сервер ответил с ошибкой. Очевидное решение — просто повторить запрос ещё раз, как только получил ошибку, незаметно для пользователя.
В одном проекте именно так мы и сделали. Всё было хорошо, пока серверу не стало плохо на пару минут. Если обычно на сервер приходили 100 запросов в минуту (полтора запроса в секунду), то за три минуты скопились 300 запросов и теперь, стоило серверу очухаться, как ему насыпали все 300 запросов в одну секунду. То есть для сервера это выглядело как рост нагрузки в 200 раз и он опять ложился под нагрузкой. Очень неприятная ситуация. Мы сами себя задидосили, своими же собственными мобильными приложениями. 🙈
Есть две компоненты решения этой проблемы:
🛑 Первая: сервер должен уметь ответить «довольно!», и клиенты должны перестать повторять запрос, если получили такой ответ. Интересно, что именно этой функции в Android-клиенте Signal не было и они добавили её во время аварии.
⏱ Вторая, более сложная и интересная, но тоже классическая: exponential backoff (экспоненциальная задержка). Идея очень простая: если сервер не ответил в первый раз — ждем 1 секунду и повторяем запрос. Во второй раз — ждем 2 секунды, в третий — 4, в четвертый — 8. То есть с каждой неуспешной попыткой, даем серверу больше времени прийти в себя. У Signal эта функция реализована, но во время аварии они добавили jitter — небольшую случайную задержку, чтобы клиенты не набегали на серверу толпой, через одинаковые интервалы времени после его падения, а нагрузка была более плавной. Обычно, в этом же коде реализуют ещё паттерн circuit breaker, когда после определённого числа ошибок «выбивает пробки» и запросы прекращаются совсем.
Используйте оба приема и будьте здоровы!
💭 Есть твит и телеграм-пост в популярном канале, в которых утверждается, что причина падения сигнала — в само-дидосе (мол, анекдот). Это маловероятно. Во первых, exponential Backoff в сигнал внедрили больше 2 лет назад и он здорово распределяет нагрузку; во вторых, изменения коснулись только Android клиента. Не верьте советским газетам, читайте первоисточники.
Люди массово переходят из вацапа в Signal. Серверы Signal не выдержали и совсем лежали почти 14 часов, а испытывали серьезные трудности больше суток. Не лучшее время, чтобы падать :( Официальный твиттер сигнала при этом хранил молчание, будто это не модный стартап, а какая-то древняя корпорация. Жаль. Надеюсь, позже они опубликуют подробный разбор, что случилось.
Пока поделюсь, как мы однажды сами положили свои серверы и как от этого защищаемся теперь. Почти все мобильные приложения отправляют запросы на сервер, например, для оформления заказа или отправки сообщения. Важно, как себя ведут мобильные приложения, если сервер ответил с ошибкой. Очевидное решение — просто повторить запрос ещё раз, как только получил ошибку, незаметно для пользователя.
В одном проекте именно так мы и сделали. Всё было хорошо, пока серверу не стало плохо на пару минут. Если обычно на сервер приходили 100 запросов в минуту (полтора запроса в секунду), то за три минуты скопились 300 запросов и теперь, стоило серверу очухаться, как ему насыпали все 300 запросов в одну секунду. То есть для сервера это выглядело как рост нагрузки в 200 раз и он опять ложился под нагрузкой. Очень неприятная ситуация. Мы сами себя задидосили, своими же собственными мобильными приложениями. 🙈
Есть две компоненты решения этой проблемы:
🛑 Первая: сервер должен уметь ответить «довольно!», и клиенты должны перестать повторять запрос, если получили такой ответ. Интересно, что именно этой функции в Android-клиенте Signal не было и они добавили её во время аварии.
⏱ Вторая, более сложная и интересная, но тоже классическая: exponential backoff (экспоненциальная задержка). Идея очень простая: если сервер не ответил в первый раз — ждем 1 секунду и повторяем запрос. Во второй раз — ждем 2 секунды, в третий — 4, в четвертый — 8. То есть с каждой неуспешной попыткой, даем серверу больше времени прийти в себя. У Signal эта функция реализована, но во время аварии они добавили jitter — небольшую случайную задержку, чтобы клиенты не набегали на серверу толпой, через одинаковые интервалы времени после его падения, а нагрузка была более плавной. Обычно, в этом же коде реализуют ещё паттерн circuit breaker, когда после определённого числа ошибок «выбивает пробки» и запросы прекращаются совсем.
Используйте оба приема и будьте здоровы!
💭 Есть твит и телеграм-пост в популярном канале, в которых утверждается, что причина падения сигнала — в само-дидосе (мол, анекдот). Это маловероятно. Во первых, exponential Backoff в сигнал внедрили больше 2 лет назад и он здорово распределяет нагрузку; во вторых, изменения коснулись только Android клиента. Не верьте советским газетам, читайте первоисточники.
кстати, лгут немного, и в твиттере и на реддите давали апдейт, что мол работаем, фиксаем ребят, обождите.
IT
да и тех детали они в своем блоге постят, можно подождать
IT
кстати там много чего интересного (в плане тех реализации и как что устроено)