С переходными процессами проблема из-за того, что коннекшены распределяются round-robin, или по хэш-таблице с числом бакетов = числу линков, так? В этом случае проблему можно решить введением consistent hash, минусом будет только неидеальная балансировка.
Конечно, в вашей архитектуре DPDK совершенно не нужен, тут я с вами полностью согласен. Я интересовался, скорее, рассматривали ли вариант с 2-4 серверами с DPDK вместо железки с FPGA. Понимаю, что вы специализируетесь на FPGA и вам ваш вариант ближе и понятнее.
OpenSSL поддерживает шифрование для non-blocking сокетов, например, в nginx используется именно такой режим.
Изолированность контекстов для отдельных клиентов — это исключительно вопрос того, как вы напишете код. Если вы контекст приклеите к файловому дескриптору, то тоже не будет никаких проблем.
Возможно, я был излишне резок, но решение «потоки vs асинхронный код с poll» — это архитектура, самый фундамент сетевого демона, и от выбора сильно зависит его внутреннее устройство. Переписать потом с одного варианта на другой чаще всего означает переписать всё. И в данном случае, я считаю, оно принято неправильно, почему — написал выше, в предыдущем комментарии.
Под ивентлупом я подразумеваю модель сетевого демона, который поллит набор сокетов каким либо образом (будь то select, epoll, kqueue или GetQueuedCompletionStatus) и обрабаывает полученные данные в одном потоке или тредпуле.
Теперь подробнее. Сетевой чат — это типичный пример сетевого демона, который практически не требует cpu в своей работе. Если делать его на потоках (я мельком глянул на ваш код, и, на сколько я понял, вы использовали именно эту модель), то совершенно бездарно тратится куча памяти и подцессорного времени на контекст-свитчи между потоками. Скажем, 1000 клиентов на дефолтовых настройках в linux отожрут 8 гигов ОЗУ на стеки потоков.
Если же сделать аналогичный демон, но на мультиплексоре типа epoll, то процессорное время будет тратиться на действительно полезную работу по перекладыванию сообщений между чат-каналами и клиентами, ну и какое-то время уйдёт на синхронизацию потоков, если их несколько. Подобный демон на аналогичной железке потянет как минимум на порядок больше клиентов, если не на два. Ещё и время ответа уменьшится, потому что будет меньше ненужной конкуренции между потоками.
Вариант с потоком на клиента имеет право на жизнь, если расчёт чего либо на cpu занимает существенное время. Скажем, если вы сделали демона рекомендательной системы, который большую нейронку/SVM гоняет на запрос. Или если ваш демон картинку ресайзит. Но если ко мне на собеседование придёт человек и будет делать чат на потоках, да ещё и заявит, что это хорошее решение, то в итогах собеседования я напишу: «про сетевое программирование очень знает мало».
Без знания сути говорить, что что-то плохо работает не есть правильно.
Вынужден не согласиться. Коллега — профессионал, уже не первый год этот эластик готовит, кучу подводных камней знает, так что его мнению я доверяю. То, что деградация есть, видно по графикам времён ответа, тут очевидно, когда работает плохо, а когда — хорошо.
Если вы действительно готовы дать дельный совет или хотите попытаться разобраться, что же происходит, то я могу свести вас в почте, например.
К сожалению, сильно больше подробностей рассказать не могу, потому как занимаюсь эластиком не я сам, а коллега. Возможно, тут играет роль нагрузка, у нас порядка 100к записей в секунду пишется, мелкими батчами, через rsyslog.
А если пихать не бездумно, то уже на 20 нодах начнут проявляться всякие неприятные спецэффекты, когда из-за временного вылета одной ноды плохет всему кластеру, хотя не должно. Скажем, перезапуск одной ноды может привести к деградации кластера минут на 20. А перезапуски нужны, потому что случаются дедлоки и null pointer exception.
В моторе стеклоочистителя 3 щётки, потому что у него две скорости. Ещё у него должен быть один провод, который замыкается или размыкается 1 раз за оборот, штатно он используется для остановки дворников в нижнем положении, а вы можете использовать для подсчёта расстояния, например.
Эластик начинает плохо работать, если в него запихать больше 20 нод. А логстэш — вообще фигня полная, в режиме приёмника UDP пакетов может терять и четверть всех логов при нескольких тысячах сообщений в секунду.
Золотовалютные резервы Китая, судя по открытым данным, не целиком в долларах, а только 30-40%%. А так там и в Евро приличная сумма, и в золоте. Чуть выше уже писали, что доля США в экспорте — около 13%, тоже не всё так ужасно.
Во-первых, обесценить доллары — это и есть цель экономической войны с США, очевидно.
В-третьих, 13%, и всё равно будут покупать, никуда не денутся. Тру-американское либо дорогое, либо еда. В волмарте почти всё китайское.
В-четвёртых, золото-евро, евробонды.
Ну и вообще, я не зря же писал про размеры экономик. КНР достаточно показать, что они готовы затянуть пояса и ориентировать производство на какую нибудь программу полёта на марс, ну или повоевать с кем нибудь. Примерно как во времена холодной войны, когда не нужно было кидаться атомными бомбами, а нужно было их только производить.
Ну конечно «запретить» — это метафора. Факт в том, что одним из крупнейших кредиторов США является КНР, почти 20% госдолга. Это такая нефиговая дубинка, которой Китай может захотеть помахать.
Факт номер два: КНР — страна с второй экономикой мира, сопоставимой с экономикой США.
Проблемы с многоэтажными домами в плотности размещения людей, электропотребителей и автомобилей. Нужны не просто розетки со счётчиками, нужны зарядные станции, которые учитывают, кто именно заряжал. Собственно, на общественных парковках как раз такие ставят.
С электричеством тоже не так просто. Уже проложенные линии рассчитаны на определённую нагрузку, просто так накинуть туда несколько киловатт можно далеко не всегда. Самый простенький tesla mobile charger способен прокачать от 3 до 10 кВт тока в аккумулятор. В домах новой постройки, где может быть подземная парковка, на каждую квартиру приходится как раз около 10 кВт, правда обычно ввод в дом меньше, чем количество квартир * максимальная допустимая мощность. Сделать сравнимое количество розеток на парковке — это проложить ещё примерно одну электросеть в доме, которая будет конкурировать за электричество с основной (особенно ярко выражено будет жарким летом, когда у всех кондиционеры, и осенью, когда включают обогреватели).
Провода между столбами освещения, конечно, тоже не рассчитаны на сотни ампер тока. То есть тоже нужно переделать всю проводку, начиная от ближайшей подстанции (и хорошо, если не переделывать и подстанцию тоже).
В частных домах с этим проще, потому что теслы есть далеко не у всех, к каждому дому уже подведены мощности (пусть даже те же 10кВт), а прокладкой новой проводки занимается каждый тесловод персонально.
Я за всех не скажу, но Amdocs Ensemble у Вымпелкома очень сложно назвать серийным биллингом. Начать можно хотя бы с того, что у самого Вымпелкома есть команда, которая в этот самый биллинг код пишет. Но, правда, совместно с командой из Amdocs, так что тут некий гибрид. Только слово «серийный» применительно к Ensemble вызывает у меня улыбку :)
При этом в мире есть успешные операторы связи, которые очень много платят вендорам (за биллинг там, за OSS/BSS, за поддержку железа), и весь штат оператора по сути сводится к менеджерам среднего звена и продуктологам/аналитикам. Если что-то нужно сделать — вендор сделает. Если что-то ломается — вендор крайне оперативно чинит. На счетах такого оператора денег остаётся не слишком много, зато и зарплатный фонд небольшой.
В США (да и в Канаде тоже) основная часть жителей живёт в одноэтажных домиках с гаражом на 2 машины. В Европе же, всё же, в многоэтажных домах. По крайней мере, в столицах и крупных городах так.
Конечно же, когда рассуждаешь о повседневном использовании электромобилей, не нужно задумываться о том, что в большей части стран золотого миллиарда потенциальные покупатели живут в городах и не имеют возможности ставить машину на зарядку ночью.
Изолированность контекстов для отдельных клиентов — это исключительно вопрос того, как вы напишете код. Если вы контекст приклеите к файловому дескриптору, то тоже не будет никаких проблем.
Возможно, я был излишне резок, но решение «потоки vs асинхронный код с poll» — это архитектура, самый фундамент сетевого демона, и от выбора сильно зависит его внутреннее устройство. Переписать потом с одного варианта на другой чаще всего означает переписать всё. И в данном случае, я считаю, оно принято неправильно, почему — написал выше, в предыдущем комментарии.
Теперь подробнее. Сетевой чат — это типичный пример сетевого демона, который практически не требует cpu в своей работе. Если делать его на потоках (я мельком глянул на ваш код, и, на сколько я понял, вы использовали именно эту модель), то совершенно бездарно тратится куча памяти и подцессорного времени на контекст-свитчи между потоками. Скажем, 1000 клиентов на дефолтовых настройках в linux отожрут 8 гигов ОЗУ на стеки потоков.
Если же сделать аналогичный демон, но на мультиплексоре типа epoll, то процессорное время будет тратиться на действительно полезную работу по перекладыванию сообщений между чат-каналами и клиентами, ну и какое-то время уйдёт на синхронизацию потоков, если их несколько. Подобный демон на аналогичной железке потянет как минимум на порядок больше клиентов, если не на два. Ещё и время ответа уменьшится, потому что будет меньше ненужной конкуренции между потоками.
Вариант с потоком на клиента имеет право на жизнь, если расчёт чего либо на cpu занимает существенное время. Скажем, если вы сделали демона рекомендательной системы, который большую нейронку/SVM гоняет на запрос. Или если ваш демон картинку ресайзит. Но если ко мне на собеседование придёт человек и будет делать чат на потоках, да ещё и заявит, что это хорошее решение, то в итогах собеседования я напишу: «про сетевое программирование очень знает мало».
Вынужден не согласиться. Коллега — профессионал, уже не первый год этот эластик готовит, кучу подводных камней знает, так что его мнению я доверяю. То, что деградация есть, видно по графикам времён ответа, тут очевидно, когда работает плохо, а когда — хорошо.
Если вы действительно готовы дать дельный совет или хотите попытаться разобраться, что же происходит, то я могу свести вас в почте, например.
Во-первых, обесценить доллары — это и есть цель экономической войны с США, очевидно.
В-третьих, 13%, и всё равно будут покупать, никуда не денутся. Тру-американское либо дорогое, либо еда. В волмарте почти всё китайское.
В-четвёртых, золото-евро, евробонды.
Ну и вообще, я не зря же писал про размеры экономик. КНР достаточно показать, что они готовы затянуть пояса и ориентировать производство на какую нибудь программу полёта на марс, ну или повоевать с кем нибудь. Примерно как во времена холодной войны, когда не нужно было кидаться атомными бомбами, а нужно было их только производить.
Факт номер два: КНР — страна с второй экономикой мира, сопоставимой с экономикой США.
С электричеством тоже не так просто. Уже проложенные линии рассчитаны на определённую нагрузку, просто так накинуть туда несколько киловатт можно далеко не всегда. Самый простенький tesla mobile charger способен прокачать от 3 до 10 кВт тока в аккумулятор. В домах новой постройки, где может быть подземная парковка, на каждую квартиру приходится как раз около 10 кВт, правда обычно ввод в дом меньше, чем количество квартир * максимальная допустимая мощность. Сделать сравнимое количество розеток на парковке — это проложить ещё примерно одну электросеть в доме, которая будет конкурировать за электричество с основной (особенно ярко выражено будет жарким летом, когда у всех кондиционеры, и осенью, когда включают обогреватели).
Провода между столбами освещения, конечно, тоже не рассчитаны на сотни ампер тока. То есть тоже нужно переделать всю проводку, начиная от ближайшей подстанции (и хорошо, если не переделывать и подстанцию тоже).
В частных домах с этим проще, потому что теслы есть далеко не у всех, к каждому дому уже подведены мощности (пусть даже те же 10кВт), а прокладкой новой проводки занимается каждый тесловод персонально.
При этом в мире есть успешные операторы связи, которые очень много платят вендорам (за биллинг там, за OSS/BSS, за поддержку железа), и весь штат оператора по сути сводится к менеджерам среднего звена и продуктологам/аналитикам. Если что-то нужно сделать — вендор сделает. Если что-то ломается — вендор крайне оперативно чинит. На счетах такого оператора денег остаётся не слишком много, зато и зарплатный фонд небольшой.