К БД обращаются. Но БД нужны специальные, рассчитанные на такие нагрузки. NoSQL в основном. Aerospike например. Кластер из 8 нод легко переживает 0.5 — 1 миллион запросов в секунду. Но там уже все в сетку и ssd упирается.
Реляционные БД используются тоже, но к ним не обращаются на каждый запрос. Только к кэшированные данным. Ну а запись в них только пакетная.
И само собой, чем больше локально кэшированных данных, тем лучше.
К внешним сервисам тоже обращаюсь. Но они должны уметь отвечать за десятки миллисекунд. Иначе, делаем очередь и уже из неё вызываем медленные сервисы.
Микросервисы (как и просто сервисы), конечно, пишутся и на C++. Я пишу, например. Но нужно понимать — зачем. Я разрабатываю рекламные платформы, нагрузка — сотни тысяч запросов в секунду, поэтому C++ позволяет получать больше производительности с одной ноды.
Думаю, что если требований к нагрузке особых нет, то и разрабатывать что то на плюсах особо не интересно. Есть куча языков с готовыми библиотеками, где многие вещи делаются в пару строк.
Когда я проектировал себе в новую квартиру вентиляцию, то смотрел на что то типа http://breezart.ru/catalog/550-humi-el-54684/
Но разместить на потолке так и не смог. А занижать весь потолок на 40см — оказался не готов.
Ну и после долгого чтения форумов, так и не определился, как дезинфецировать его. Если в настольном жизнь заводится, то и в этом будет. Но незаметно :(
Есть и термопоты с подключением к водопроводу. И кофемашины с ним же. И канальные увлажнители. Но стоит это все слишком много. И габариты большие для квартир, к сожалению :(
Понятно, что у каждого свой юзскейс.
Но мне в моей ситуации (highload сервисы) удобно либо стандартную смотрелку из mc поюзать (это когда логи маленькие), либо уже греп и tail (когда логи в десятки гигабайт).
Когда что то совсем большое — проще написать на C многопоточный парсер (по давно готовому шаблону) и получить выгрузку/агрегацию очень быстро.
С другой стороны — мои логи в ДЦ и часто очень большие. Это накладывает свои ограничения, да.
В МСК, кстати, в яндекс-драйве есть детские кресла. Ездили с годовалым ребенком на вокзал, а потом в аэропорт (опоздали на поезд из-за кортежа :) ) — вполне норм. Но тачку такую надо еще поискать. Пришлось ездить за машиной на другом каршеринге. Кошмар, но что делать(
PS. Своя машина есть. Но как быть, когда надо добраться в аэропорт/на вокзал с семьей? Куда потом машину деть, если некому ее забрать. А в такси кресел для годовалых детей нет( Даже в бизнес/премиум/убер/вилли и т п. Только 3года+.
1xbet, фонбет и им подобные — это не казино, как бы странно это не выглядело. Такие законы. Хотя чем от них отличаются те же бинарные опционы или казино — не особо понятно.
Потому что под оптимизацией процессов обычно понимают штрафы/задержку карьерного роста и иные схемы мотивации.
Как будто в советское время таких KPI не было. И реагировали на них так же. И сообща били морду (если могли, конечно :) ) стахановцу, из-за которого всему цеху поднимали план выработки
Люди, они такие. Ходят на работу за зарплатой обычно. Любят кушать и покупать игрушки детям своим и украшения женам. Ездить в отпуск в новые страны. И кучу всего.
Если же вы смогли найти сотрудников, которые искренне поддерживают ваш KPI и не стараются сломать/обойти/хакнуть его, а стопроцентно соблюдают (даже в ущерб себе) — ну молодцы вы. Счастья, здоровья и как там наш премьер говорил
Может у вас все и хорошо с точки зрения всяких метрик, подходов и концепций. И даже инструменты, возможно, подходящие. Не суть.
Но вот когда личный кабинет постоянно разлогинивает тебя. И в него не всегда (или всегда не) получается зайти с первого-второго раза и приходится настаивать.
Или когда список товаров из отложенных или корзины — просто пропадает и надо все собирать заново.
Про чудо поиск уже написали. И про «наличие» в магазине.
И ещё оплата интернет заказа часто срывается и надо повторять.
Вот с этими информационными «технологиями» и сталкивается обычный покупатель.
«Повторите последнее действие...»
Сам магазин нравится. Ассортиментом и количеством точек присутствия. Но сайт — жуть жуткая по удобству использования
Использую CLion уже больше года — все нравится.
Но пару дней назад переехал на ноутбуке с macos high sierra на ubuntu 19.04.
И начались сильные тормоза из-за CLion. При редактировании проекта использование cpu подскакивает на максимум. При включенном power saving режиме такого нет.
Под макосью таких проблем не наблюдалось. Проекты ровно те же самые редактировались.
Грустно :(
Да и на сайте разработчика есть тесты. Ну да ладно, все равно всегда надо под свой профиль нагрузки выбирать. И тестить самому.
Но циферки хорошие в документации написаны.
Хотя я больше люблю AP использовать. Бизнесс-процессы позволяют неконсистентность. А вот падение ноды бывает не так уж часто. Из-за дисков, как правило. И мне нравится, что пока нода поднимается, аэроспайк запись работает как ни в чем не бывало. Но с просадкой по латнеси, конечно
Статья именно что первый взгляд. Без тестов это просто еще одна KV бд.
Да, она реализует CP, а не AP как многие другие. И транзакции есть вроде. Но вопрос — насколько они тормозят?
Впрочем, если можно прожить без транзакций, с AP (вместо CP) и без сортировки ключей — то быстрее aerospike еще ничего больше не видел.
В любом случае, спасибо за статью — будет свободное время, поставлю в ДЦ и потестирую
Для TCP есть библиотеки под dpdk. А http не так уж и сложно/заумно реализовывать, если надо.
Понятно, что для раздачи статики лучше взять nginx- его все админы умеют настраивать.
Ну и использовать http для высокой нагрузки — это глупо. Канал загружает плохо (да, я знаю про http Pipelining), накладных расходов на заголовки много. Бинарные протоколы рулят.
А как на счёт поддержки clang-format? Хотя бы на уровне qtcreator — при сохранении запускается clang-format для файла/файлов.
Ну и конечно, поддержка if (auto it = map.find(); it != map.end()) из C++17.
Вот отсутствие этих двух вещей очень мешает перейти наконец на CLion с qtcreator
Это в сравнении с медицинскими центрами-лабораториями, которые не стартапы и хоть как-то (в теории) отвечают за результат.
А так — красивые картинки и циферки сейчас любой школьник умеет генерить. Вопрос в достоверности полученных данных.
К БД обращаются. Но БД нужны специальные, рассчитанные на такие нагрузки. NoSQL в основном. Aerospike например. Кластер из 8 нод легко переживает 0.5 — 1 миллион запросов в секунду. Но там уже все в сетку и ssd упирается.
Реляционные БД используются тоже, но к ним не обращаются на каждый запрос. Только к кэшированные данным. Ну а запись в них только пакетная.
И само собой, чем больше локально кэшированных данных, тем лучше.
К внешним сервисам тоже обращаюсь. Но они должны уметь отвечать за десятки миллисекунд. Иначе, делаем очередь и уже из неё вызываем медленные сервисы.
Микросервисы (как и просто сервисы), конечно, пишутся и на C++. Я пишу, например. Но нужно понимать — зачем. Я разрабатываю рекламные платформы, нагрузка — сотни тысяч запросов в секунду, поэтому C++ позволяет получать больше производительности с одной ноды.
Думаю, что если требований к нагрузке особых нет, то и разрабатывать что то на плюсах особо не интересно. Есть куча языков с готовыми библиотеками, где многие вещи делаются в пару строк.
Когда я проектировал себе в новую квартиру вентиляцию, то смотрел на что то типа http://breezart.ru/catalog/550-humi-el-54684/
Но разместить на потолке так и не смог. А занижать весь потолок на 40см — оказался не готов.
Ну и после долгого чтения форумов, так и не определился, как дезинфецировать его. Если в настольном жизнь заводится, то и в этом будет. Но незаметно :(
Есть и термопоты с подключением к водопроводу. И кофемашины с ним же. И канальные увлажнители. Но стоит это все слишком много. И габариты большие для квартир, к сожалению :(
Понятно, что у каждого свой юзскейс.
Но мне в моей ситуации (highload сервисы) удобно либо стандартную смотрелку из mc поюзать (это когда логи маленькие), либо уже греп и tail (когда логи в десятки гигабайт).
Когда что то совсем большое — проще написать на C многопоточный парсер (по давно готовому шаблону) и получить выгрузку/агрегацию очень быстро.
С другой стороны — мои логи в ДЦ и часто очень большие. Это накладывает свои ограничения, да.
grep, awk, head + tail
Ну вы чего, какой notepad?!
Отключать keep-alive из-за высокой нагрузки в микросервисном окружении — это вин!
PS. Своя машина есть. Но как быть, когда надо добраться в аэропорт/на вокзал с семьей? Куда потом машину деть, если некому ее забрать. А в такси кресел для годовалых детей нет( Даже в бизнес/премиум/убер/вилли и т п. Только 3года+.
Как будто в советское время таких KPI не было. И реагировали на них так же. И сообща били морду (если могли, конечно :) ) стахановцу, из-за которого всему цеху поднимали план выработки
Если же вы смогли найти сотрудников, которые искренне поддерживают ваш KPI и не стараются сломать/обойти/хакнуть его, а стопроцентно соблюдают (даже в ущерб себе) — ну молодцы вы. Счастья, здоровья и как там наш премьер говорил
Может у вас все и хорошо с точки зрения всяких метрик, подходов и концепций. И даже инструменты, возможно, подходящие. Не суть.
Но вот когда личный кабинет постоянно разлогинивает тебя. И в него не всегда (или всегда не) получается зайти с первого-второго раза и приходится настаивать.
Или когда список товаров из отложенных или корзины — просто пропадает и надо все собирать заново.
Про чудо поиск уже написали. И про «наличие» в магазине.
И ещё оплата интернет заказа часто срывается и надо повторять.
Вот с этими информационными «технологиями» и сталкивается обычный покупатель.
«Повторите последнее действие...»
Сам магазин нравится. Ассортиментом и количеством точек присутствия. Но сайт — жуть жуткая по удобству использования
Но пару дней назад переехал на ноутбуке с macos high sierra на ubuntu 19.04.
И начались сильные тормоза из-за CLion. При редактировании проекта использование cpu подскакивает на максимум. При включенном power saving режиме такого нет.
Под макосью таких проблем не наблюдалось. Проекты ровно те же самые редактировались.
Грустно :(
Но циферки хорошие в документации написаны.
Хотя я больше люблю AP использовать. Бизнесс-процессы позволяют неконсистентность. А вот падение ноды бывает не так уж часто. Из-за дисков, как правило. И мне нравится, что пока нода поднимается, аэроспайк запись работает как ни в чем не бывало. Но с просадкой по латнеси, конечно
Да, она реализует CP, а не AP как многие другие. И транзакции есть вроде. Но вопрос — насколько они тормозят?
Впрочем, если можно прожить без транзакций, с AP (вместо CP) и без сортировки ключей — то быстрее aerospike еще ничего больше не видел.
В любом случае, спасибо за статью — будет свободное время, поставлю в ДЦ и потестирую
Для TCP есть библиотеки под dpdk. А http не так уж и сложно/заумно реализовывать, если надо.
Понятно, что для раздачи статики лучше взять nginx- его все админы умеют настраивать.
Ну и использовать http для высокой нагрузки — это глупо. Канал загружает плохо (да, я знаю про http Pipelining), накладных расходов на заголовки много. Бинарные протоколы рулят.
А как на счёт поддержки clang-format? Хотя бы на уровне qtcreator — при сохранении запускается clang-format для файла/файлов.
Ну и конечно, поддержка if (auto it = map.find(); it != map.end()) из C++17.
Вот отсутствие этих двух вещей очень мешает перейти наконец на CLion с qtcreator
Отправил письмо сразу же, как узнал о нововведении. Не помогло :(
А так — красивые картинки и циферки сейчас любой школьник умеет генерить. Вопрос в достоверности полученных данных.