Просто пишите код. Часть 1

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

а зачем его покупать сразу? сервер может расти за Прибылью.

в общем, парадигма ИЗМЕНИЛАСЬ! еще лет 10 назад каждая первая статья о Масштабировании вполне резонно отмечала, что Вертикальное Масштабирование вас НЕ вывезет...

но!

на сегодняшний день ваш Бизнес сдохнет раньше, чем вы исчерпаете возможности одного Хорошего Сервера.

ЗЫ расчлененка - дополнительная Сложность! зачем себе портить Жизнь, если можно не портить?

Просто пишите код. Часть 1

на сегодняшний день, микросервисы - некогда и незачем!

как я уже здесь цитировал:

Если вы давно не смотрели на серверное оборудование, то обнаружите, что современные высокопроизводительные серверы — это целые датацентры в коробке! Я просто ткнул Dell и нашел следующие характеристики PowerEdge R960:

• 240 ядер (4 сокета по 60 ядер в каждом)

• 16 ТБ ОЗУ в 64 модулях DDR5 DIMM (это как 1000 приличных ноутбуков)

А если нужно хранилище, то вы можете подключить до 24 NVMe дисков — по 4 ТБ каждый, а это почти 100 ТБ высокоскоростного SSD! И если 240 ядер вам покажется маловато, то Intel анонсировала процессоры Xeon с 288... Уже прямо сейчас вы можете подключить два Xeon 6780 к PowerEdge R770 серверу, получив в общей сложности 288 ядер, по цене около USD 32k.

Большинство enterprise-scale архитектур основаны на предположении, что одной машины недостаточно для обработки требуемой рабочей нагрузки. Большинство облачных решений, особенно serverless, основаны на той же предпосылке: если вам нужно что-то масштабировать, то оно должно быть distributed! Вторым вопросом является отказоустойчивость: в распределенной, масштабируемой системе легче обработать отказ одного компонента и, таким образом, увеличить uptime.

Сколько операционных данных хранит ваше бизнес-приложение? 1 мегабайт на клиента? Тогда 1 миллион клиентов потребуют всего 1 ТБ. И у нас еще осталось довольно много свободного пространства — в оперативной памяти! 1000 запросов в секунду к in-memory database? Я почти гарантирую вам, что у вас больше, чем несколько ядер CPU будет простаивать. 10 000 запросов (40 на ядро ​​в секунду) или даже 50 000 звучит более правдоподобно.

А как насчет отказоустойчивости? Все постоянно выходит из строя, верно? По крайней мере, так сказал Werner Vogels, но это было в 2008 году, когда AWS была немного больше, чем S3, SQS и EC2, последний из которых только что вышел из публичной бета-версии и получил SLA — возможно, это взаимосвязано. Современные серверы имеют избыточные, сменные блоки питания и вентиляторы, диски с возможностью горячей замены, а некоторые, как утверждается, даже имеют сменную оперативную память! Тем не менее, вы не будете хранить все свои данные только в оперативной памяти, а будете писать в persistent log, который позволит вам восстановить состояние системы в случае сбоя. Для большого сервера это может занять некоторое время. Например, если у вас будет 2 сбоя оборудования в год и время восстановления составляет 30 минут, то вы все равно получите 4 девятки, примерно столько же, сколько вам обещает большинство облачных сервисов. В действительности вы, вероятно, разобьете свою систему на более мелкие компоненты: на высокодоступные, и другие, которые могут позволить себе немного более длительное MTTR.

https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f

О том, как легкомысленное использование полиморфных аллокаторов может испортить вам жизнь

люди!
таки сделайте два шага от телевизора и внимательно посмотрите, что вы тут пишете...

вот эта ДЛИННЮЩАЯ ПРОСТЫНЯ текста - разве она решает хоть одну полезную задачу?

нет!
вы Героически Боритесь с врожденными недостатками STL и копирования/перемещения С++. и вы опять проиграете!

зачем тратить время на глупости, когда уже знаете, КАК программировать в удовольствие?

О том, как легкомысленное использование полиморфных аллокаторов может испортить вам жизнь

Меняем канализационные трубы, прочищаем унитазы. Недорого. Без пафоса.

а тесты производительности запускали? вдруг и правда "МНОГОКРАТНОЕ ускорение"

О том, как легкомысленное использование полиморфных аллокаторов может испортить вам жизнь

  Bacteria() = default;
  Bacteria(const Bacteria&) = default;
  Bacteria(Bacteria&&) = default;
  Bacteria& operator = (const Bacteria&) = default;
  Bacteria& operator = (Bacteria&&) = default;
  ~Bacteria() = default;

мой бог, Чудовищное(tm) зрелище!!! вот за это ненавидят и боятся C++.

уже давно писал и объяснял: переходите на sh_ptr/mem_pool и получите МНОГОКРАТНОЕ ускорение без мути https://ders.by/cpp/norefs/norefs.html#4.3

ЗЫ плюс научитесь различать Чудовищное...

С++ — это настоящий кайфǃ

А можете свои умозрительные заключения подтвердить

увы, я только вышел поболтать. и никакого отношения ни к Архитектуре, ни к IP-телефонии не имею))

Java используется повсеместно и как раз в КРУПНЕЙШИХ проектах

так спросите "в КРУПНЕЙШИХ проектах", как они тюнят GC. и что все равно происходит.

С++ — это настоящий кайфǃ

ок, давайте посмотрим на Архитектуру.

например, в IP-телефонии нужно за 100ms принять решение: разрешаем звонок или нет? по какому тарифу?
вопрос: а на какое время Java-сервис зависает в мусорке?

и еще.

если падает процесс Сервиса - это проблема, но не беда.
а вот когда морозится на несколько секунд, а потом продолжает как ни в чем не бывало... это уже БЕДА!

Разработка дешёвая и стабильная

только на мелких проектах.

С++ — это настоящий кайфǃ

прочитал, ссылка точно правильная?

ну, давайте читать вместе:

1. pdf называется "Distilling the Real Cost of Production Garbage Collectors"

2. и начинается с "Despite the long history of garbage collection (GC) and its prevalence in modern programming languages, there is surprisingly little clarity about its true cost. Without understanding their cost, crucial tradeoffs made by garbage collectors (GCs) go unnoticed."

инфа там конечно для маленьких, но будет полезна и взрослым.

С++ — это настоящий кайфǃ

Вы смеётесь что ли?

ДА!
я сейчас мерзко хихикаю, потирая потные ладошки)))

но никак не за производительность

вы просто не понимаете, с кем разговариваете
мне еще лет 20 назад "прогрессивная общественность" пела байки про "инкрементальный GC", не делающий stop the world... даже Страуструп топил за GC в C++, а потом "вдруг" одумался ;)

короче, в https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f есть ссылки прямо по теме. постарайтесь понять ЧТО там написано Специалитами.

Жаба - это не только расход памяти. GC жабы - позор.

С++ — это настоящий кайфǃ

пример сравнения языков на реальных задачах

как и все остальные, вы сейчас не учитываете один маленький, но очень ключевой момент:

Ради этого места реального бизнеса АБСОЛЮТНО нет смысла стараться. Хуже дурака -- только дурак с инициативой!

Нет смысла стараться нигде, кроме узкого места (bottleneck). Но развальцуете бизнесу bottleneck -- он сразу пойдет веселее!

читайте https://ders.by/arch/scale/scale.html

С++ — это настоящий кайфǃ

Я много лет писал на С++ и могу вам сказать, что он не быстрее ни на 92%, ни на 82%

если честно, то я тоже много лет писал на С++
и могу вам сказать, что mp_allocator дает ускорение в 5-8 раз, а не жалкие 100%
https://ders.by/cpp/norefs/norefs.html#4.2

и везде и всегда, GC - это УБИЙЦА производительности многопоточных приложений!

Как чужая ошибка в коде сожгла $100,000 на Firebase: спасаем стартап и разбираемся, какой сервер вам реально нужен

факт в том, что на сегодняшний день мелким и средним бизнесам ВООБЩЕ не нужна распределенка, k8s и прочие гадости:

Большинство enterprise-scale архитектур основаны на предположении, что одной машины недостаточно для обработки требуемой рабочей нагрузки. Большинство облачных решений, особенно serverless, основаны на той же предпосылке: если вам нужно что-то масштабировать, то оно должно быть distributed! Вторым вопросом является отказоустойчивость: в распределенной, масштабируемой системе легче обработать отказ одного компонента и, таким образом, увеличить uptime.

Сколько операционных данных хранит ваше бизнес-приложение? 1 мегабайт на клиента? Тогда 1 миллион клиентов потребуют всего 1 ТБ. И у нас еще осталось довольно много свободного пространства — в оперативной памяти! 1000 запросов в секунду к in-memory database? Я почти гарантирую вам, что у вас больше, чем несколько ядер CPU будет простаивать. 10 000 запросов (40 на ядро ​​в секунду) или даже 50 000 звучит более правдоподобно.

А как насчет отказоустойчивости? Все постоянно выходит из строя, верно? По крайней мере, так сказал Werner Vogels, но это было в 2008 году, когда AWS была немного больше, чем S3, SQS и EC2, последний из которых только что вышел из публичной бета-версии и получил SLA — возможно, это взаимосвязано. Современные серверы имеют избыточные, сменные блоки питания и вентиляторы, диски с возможностью горячей замены, а некоторые, как утверждается, даже имеют сменную оперативную память! Тем не менее, вы не будете хранить все свои данные только в оперативной памяти, а будете писать в persistent log, который позволит вам восстановить состояние системы в случае сбоя. Для большого сервера это может занять некоторое время. Например, если у вас будет 2 сбоя оборудования в год и время восстановления составляет 30 минут, то вы все равно получите 4 девятки, примерно столько же, сколько вам обещает большинство облачных сервисов. В действительности вы, вероятно, разобьете свою систему на более мелкие компоненты: на высокодоступные, и другие, которые могут позволить себе немного более длительное MTTR.

вот ссылка, если нужны подробности: https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f

С++ — это настоящий кайфǃ

сейчас я абсолютно искренне радуюсь тому как легко и непринужденно работает джава

а теперь посмотрите на это:

1. by using GC, applications spend 7–82% more wall-clock time and 6–92% more CPU cycles relative to their intrinsic costs.

2. both Shenandoah and ZGC have worse (by factors of 10–100×) query latencies than the other three collectors!

отсюда https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f

С++ — это настоящий кайфǃ

не понимаю как получать кайф от std::chrono

почитайте главу 5.7 Clocks and Timers

книги Nicolai M. Josuttis-The C++ Standard Library, 2nd Edition_ A Tutorial and Reference-Addison-Wesley (2012).pdf

С++ — это настоящий кайфǃ

Если вы пытаетесь сделать проект, конкурирующий с тем, на котором зарабатывает Диктатор — тогда будьте готовы к тому, что вас будут годами, так сказать, «травить собаками».

абсолютно в точку!

"Здесь вообще всё просто так, кроме денег" (ц)

HashMap под микроскопом

смиялсо.

ну покажите мне еще один "велосипед", где копирование объекта HashMap со всеми ее элементами - это просто memcpy()? джависты даже не поймут суть вопроса.

HashMap под микроскопом

а бывает HashMap с транзакциями. но на Жабе у вас не получится.

https://ders.by/cpp/memdb/memdb.html

Секреты в Java-сервисах на Spring: где брать и как обновлять

Используем 2 варианта

хехе. для начала контекст новым читателям:

давайте рассмотрим сферический Vault в вакууме:

1.мы ставим на Linux сервер нативное Приложение.

2.у Приложения есть конфиг и ему нужно работать с Базой.

а дальше уже интересно:

3.все знают, что пароль к Базе нельзя хранить в конфиге!

4.все знают, что пароль к Базе нужно хранить в Vault.

итак, наш Vault - тоже База. база секретов.

и вы только что нам сказали, что у вас есть "2 варианта" безопасного соединения с Vault. прекрасно!

так почему бы Приложению сразу не использовать эти "2 варианта" для прямого соединения с Базой без всякого Vault?

1. если "2 варианта" безопасны, то Vault не нужен. (не улучшает Безопасность)

2. если "2 варианта" НЕ безопасны, то Vault не нужен тем более!! (он ухудшает Безопасность)

Секреты в Java-сервисах на Spring: где брать и как обновлять

каждое обращение аутентифицируется (либо уже имеющийся токен... либо множество других вариантов аутентификации)

вы не поняли сути вопроса.

если для доступа к ПровайдеруСекретов необходим токен, то вам нужен ПровайдерСекретов2 ;)

Сквозное шифрование в облаках. Уязвимости — во всех сервисах

и взрослые вроде люди... зачем разбирать сказки?

галочка на UI - это просто галочка. шифруйте сами локально. только так.