во-первых, общая скорость домашнего интернета гарантированно просядет, ведь оборудованию провайдера придется не просто пропускать трафик, а постоянно сверяться с «белыми списками»
То есть, фильтровать пакеты, выискивая в них запрещенные протоколы, что происходит уже сейчас, это норм. А просто свериться с белым списком это долго? Тем более, сейчас что не проверяют заблокированные IP?
Сейчас народ пытается использовать VPS (например, в Сберклауде — там виртуалка бесплатная, платишь только 149р за белый IP
Чем поможет VPS на Сберклауде. На трафик от Сбералкауда нет ограничений? Речь про защиту частных сетей или про доступ к заблокированным сайтам типа ютуб?
Скрипт сам подменяет заголовки, пытается «замаскировать» протокол под обычный HTTPS
Это цитата про
whitelist-bypass или специализированные сборки AmnesiaVPN/`AmneziaWG
А что vless+reality не маскирует трафик под обычный https? Как раз, маскирует. Другое дело, что это тоже палится
Спасибо за статью. Есть несколько моментов (не про Spring, но про grpc), которые представляют сложность, особенно, при миграции из json/openApi на grpc:
1) Что с логированием Grpc-объектов? В общем случае хочется залогировать в удобно-читаемом виде "все что пришло на вход" и "все что ушло", замаскировав чувствительные данные. В json это делается на раз, с grpc с этим были проблемы - стандартное логирование не кастомизируется, ObjectMapper не применим из-за сложной структуры grpc-объектов
2) proto-схемы поддерживают указание ограничений на поля, аналогично схемам данных json? Спринговая валидация это поддерживает?
3) Java 17 достаточна для Spring gRPC 1.0? (вроде, да)
4) Еще один момент: правила маршрутизации на основе Istio (Virtual Service+Destination Rule) часто завязываются на URL, а в случае с GRPC URL всегда корневой, и могут понадобиться дополнительные доработки (например, добавление заголовков) для того, чтобы понимать, какой именно сервис вызван
Спасибо за развернутые пояснения! Задавая вопрос, я тоже полагал, что вы используете, что-то вроде akka streams в java (реактивные стримы, обратное давление, гринтреды, дросселирование). Сам за эту тему активно топлю, но, к сожалению, реалии пока не позволяют использовать активно эти технологии. Для этого, во-первых, нужно, чтобы все взаимодействующие компоненты поддерживали реактивность, вот, вы говорите, что взяли и избавились от базы — мы пока не можем. Во-вторых, перейти на асинхронное stateless взаимодействие всех микросервисов и компонент тоже достаточно проблематично.
Но, вот, вы пишете:
тут просто нагружаем процессор, пока не выйдем на 95%
А какими средствами вы регулируете нагрузку именно в цифрах утилизации CPU? Понятно, что, скажем, в java/akka есть пулы гринтредов (ForkJoinPool), которые по-умолчанию создают столько физических потоков сколько ядер процессора и таким образом должны оптимально использовать имеющиеся вычислительные ресурсы, но как выйти именно на цифру, скажем, в 95% мне непонятно.
Вообще когда вы параллелите операции ввода-вывода, http запрос например, то получаете ускорение за счет того что процессор переключает своей выпонение на полезную нагрузку
Собственно, об этом я в статье и написал. А начальный пост был о том, что при 4 физических и 8 логических ядрах правильно ожидать прироста производительности кратного количеству физических ядер, то есть в 4 раза. То что он может быть больше и зависит от типа задач, само собой разумеется.
И снова нет. ∀ ε > 0: 100 + ε — да. А ровно 100 — нет.
Знать бы еще как обеспечить эти «чуть меньше 100%». Нагрузка обычно неравномерна, поэтому и нужен запас прочности, чтобы «чуть меньше 100%» сейчас не превратились в «чуть больше 100%» через некоторое время. Системы, которые вы разрабатываете, позволяют это обеспечить? Интересно, что это за системы? Какая у них функциональность?
Утилизация меньше 95% — для нас явный сигнал, что мы что-то делаем неправильно
То есть, если на серверах, где работает разрабатываемое вами ПО снять в динамике утилизацию процессора, она будет >95%?
Ни на опыт, ни на статистику вы не ссылались. Вы сказали, что они высосали из пальца нелепую цифру в 80%.
Собственно, спор возник вокруг моего утверждения, что на практике утилизация CPU не должна превышать 80% для обеспечения отказоустойчивости. И я привел пример где такая практика имеет место. Я не говорю, что невозможно построить систему, которая будет отлично работать при стабильной загрузке CPU >95%, но большинство систем, опять же, по моему опыту не такие.
Есть логика, которая «предполагает» и есть статистика, которая «располагает». Я полагал, что мы оба понимаем, что утилизация CPU = 100%, это значит, что «сервер встал» и мы спорим лишь о цифре запаса прочности. Если надо обосновать логически почему цифра в 100% загрузки CPU недопустима — пожалуйста. 100% загрузки CPU означает, что мы даем на процессор такую нагрузку, что он не справляется и задачи выстраиваются в очередь, которая постоянно растет. Иными словами, время выполнения каждой задачи (например, запроса пользователя, SQL-запроса в БД) критично увеличивается. И мой практический опыт подтверждает эту логику. Чтоб это доказать нужно сделать пример и провести нагрузочное тестирование. В переписке, как вы понимаете, это невозможно.
С каких пор «критерии тестирования в [название любой конторы]» — являются доказательной базой?!
Доказать эту конкретную цифру можно только статистикой. Я сослался на опыт (статистику) IT специалистов уважаемой компании. Как еще это можно доказать?
Этот комментарий относился к виртуальным ядрам, и в нем фигурировали цифры 50-60% (тоже нуждающиеся в аргументации, кстати). Каким боком его вообще можно сюда приплести?
Речь шла о том, что реального прироста производительности после некоторой цифры утилизации CPU на графике можно не ждать.
В Сбербанке при проведении нагрузочного тестирования одним из критериев его успешности была цифра в 80% утилизации CPU. Запас прочности в 20% кажется вполне обоснованным, особенно с учетом комментария edo1h
То есть, фильтровать пакеты, выискивая в них запрещенные протоколы, что происходит уже сейчас, это норм. А просто свериться с белым списком это долго? Тем более, сейчас что не проверяют заблокированные IP?
Чем поможет VPS на Сберклауде. На трафик от Сбералкауда нет ограничений? Речь про защиту частных сетей или про доступ к заблокированным сайтам типа ютуб?
Это цитата про
А что vless+reality не маскирует трафик под обычный https? Как раз, маскирует. Другое дело, что это тоже палится
Спасибо за статью. Есть несколько моментов (не про Spring, но про grpc), которые представляют сложность, особенно, при миграции из json/openApi на grpc:
1) Что с логированием Grpc-объектов? В общем случае хочется залогировать в удобно-читаемом виде "все что пришло на вход" и "все что ушло", замаскировав чувствительные данные. В json это делается на раз, с grpc с этим были проблемы - стандартное логирование не кастомизируется, ObjectMapper не применим из-за сложной структуры grpc-объектов
2) proto-схемы поддерживают указание ограничений на поля, аналогично схемам данных json? Спринговая валидация это поддерживает?
3) Java 17 достаточна для Spring gRPC 1.0? (вроде, да)
4) Еще один момент: правила маршрутизации на основе Istio (Virtual Service+Destination Rule) часто завязываются на URL, а в случае с GRPC URL всегда корневой, и могут понадобиться дополнительные доработки (например, добавление заголовков) для того, чтобы понимать, какой именно сервис вызван
Но, вот, вы пишете:
А какими средствами вы регулируете нагрузку именно в цифрах утилизации CPU? Понятно, что, скажем, в java/akka есть пулы гринтредов (ForkJoinPool), которые по-умолчанию создают столько физических потоков сколько ядер процессора и таким образом должны оптимально использовать имеющиеся вычислительные ресурсы, но как выйти именно на цифру, скажем, в 95% мне непонятно.
Собственно, об этом я в статье и написал. А начальный пост был о том, что при 4 физических и 8 логических ядрах правильно ожидать прироста производительности кратного количеству физических ядер, то есть в 4 раза. То что он может быть больше и зависит от типа задач, само собой разумеется.
Знать бы еще как обеспечить эти «чуть меньше 100%». Нагрузка обычно неравномерна, поэтому и нужен запас прочности, чтобы «чуть меньше 100%» сейчас не превратились в «чуть больше 100%» через некоторое время. Системы, которые вы разрабатываете, позволяют это обеспечить? Интересно, что это за системы? Какая у них функциональность?
То есть, если на серверах, где работает разрабатываемое вами ПО снять в динамике утилизацию процессора, она будет >95%?
Собственно, спор возник вокруг моего утверждения, что на практике утилизация CPU не должна превышать 80% для обеспечения отказоустойчивости. И я привел пример где такая практика имеет место. Я не говорю, что невозможно построить систему, которая будет отлично работать при стабильной загрузке CPU >95%, но большинство систем, опять же, по моему опыту не такие.
Доказать эту конкретную цифру можно только статистикой. Я сослался на опыт (статистику) IT специалистов уважаемой компании. Как еще это можно доказать?
Речь шла о том, что реального прироста производительности после некоторой цифры утилизации CPU на графике можно не ждать.