Asio+Fibers

Есть такой мега пополярный фрэймворк для С++ - асио ... Ну вы в крусе =) Их какбы 2 - тот что живет отдельно и в бусте. Я говорю про тот что отдельно и живет на гитхабе. Тот кто смотрел реализацию и профайлил это дело, то видел что основное время уходит на лок в главном евентлупе, при вызове обработчиков. Причем там тупо мьютекс, что мега сильно все просаживает... Это в реакторе если что, для уточнения я говорю про никсы и еполл соответственно. Так вот, когда 1 поток там можно вроде сказать чтоб лока не было (это логично у нас будет однопоточное приложение), но при нагрузках 1 поток не вывозит и я раскидываю на к-во ядер. Так вот, к чему я веду! относительно недавно родилась библа в бусте фибер и там уже есть пример связки с асио. Смак в том, что в теории должен некисло прирости буст обработки сетевых событий итд. Пробовал ли кто уже это в продакшене? Тестовое я гонял и мне понравилось, но вот переводить боевой софт я пока стремаюсь.
Возможно это вопрос к _DEN_ у. Я помню он тащился от асио лет 7-8 назад...

 

Дай каждому потоку свой io_service и им не понадобится синхронизация. Я кстати не помню чтобы какие-то дела с синхронизацией просаживали время. Хотя я никогда не использовал один и тот же io_service из разных потоков. Как-то раз увидел пример сервера в доках буста, там чел сделал round-robin контейнер пар поток+io_service, и выдавал их входящим подключениям. Мне это понравилось и далее я делал только на такой архитектуре.

 

Хотя что я несу, лол. Треды io_service::run это треды обработки, а отправка заданий в любом случае должна быть синхронизирована.

 

Поэтому на самом деле начать нужно с этого:

Результаты тестирования есть, или это просто домысел?

 

Чето да. Ты в начале странное написал) иосревис 1 но ранниться на много потоков. Стандартная архитектура. Результаты тестирования чего с чем? Яж написал, что в профайлере под нагрузкой в основном это ожидание лока в реакторе. Чтобы от этого уйти есть вариант с фиберами, но в продакшене не юзал. Это уже другая архитектура. Не так как обычно с асио. Естественно полноценный тест я не городил ибо лень, думал может так уже делал кто. По идее похоже на эрлан чуть с зелеными потоками.

 

superakira, но все-таки, может попробовать архитектуру "каждому потоку свой io_service"? В таком виде операций, которым нужна синхронизация, будет гораздо меньше (одна на соединение), и может это перестанет быть проблемой. Фиберы не юзал, позырю.

 

взаимоблокировка потоков очень частая трабла.

 

_DEN_, каждому потоку свои сервис - это мега порочная идея... во первых тогда будет несколько евентлупов, соотв несколько очередей итд итп, как ты будешь строить сервер например? асио так будет работать только хуже - на самом деле синхронизаций будет только больше.
Ладно. Если запилю что дельное с фиберами и увижу лютый буст - отпишу для след поколений.

 

Ну да, у каждого потока будет своя собственная очередь. Только почему это плохо?

Это почему?

http://www.boost.org/doc/libs/1_63_...st_asio.examples.cpp03_examples.http_server_2 -> http://www.boost.org/doc/libs/1_63_...xample/cpp03/http/server2/io_service_pool.hpp
Далее действительно идет HTTP Server 3, в котором io_service всего один. Но все-таки хотелось бы получить объяснение почему много io_service-ов это плохо, со ссылкой на исходники, или хотя бы на низлежащее апи оси.

 

Вообще, все зависит от архитектуры сервера. Если он stateless (например - принимает число и выдает его простые множители, т.е. чисто вычисления, без состояний), то удобнее брать обычный тредпул - то есть один io_service + пачка обслуживающих потоков. Если у сервера есть множество изолированных состояний (например это MMO-сервер, а состояние - это набор данных об игровом инстансе), то мне кажется, что удобнее брать как в примере HTTP Server 2 (пары сервисов и тредов), потому что тогда хендлеры тасок инстанса будут отрабатываться в одном и том же потоке, и им не понадобится дополнительная синхронизация при работе с состоянием инстанса.

Но будет конечно интересно посмотреть на твой опыт работы с фиберами (я за 5 минут насилил, а на большее пока что нет времени), так что напиши пожалуйста когда этот опыт будет

 

по большей части всё упирается в вопрос КАКОЙ ВАРИАНТ ЖРЁТ БОЛЬШЕ ОЗУ. более прожорливый повышает вероятность свопа, а сие есмь ..опа ;D

 

UbIvItS, в продакшене это должна быть достаточно специфичная задача и достаточно жадный хозяин, чтобы ось ушла в своп. Сервак с 256 гб озу стоит меньше 150 евро в месяц.

 

хммм.. это где такие расценки? вот, к примеру, сюда смотрю https://www.ovh.com/us/dedicated-servers/ к тому же, 256 гиг озу для сервача на заоблачное явно не тянет ==>> пущай на каждого игрока уходит в среднем один гиг (и, ведь, этЪ жежЪ скромно).

 

https://www.hetzner.de/hosting/produkte_rootserver/px121

У разных хостеров сборка имеет разные перекосы. Кто-то больше в данные, кто-то больше в вычисления, кто-то больше в ширину канала. Нужно искать под свои личные нужды, с учетом тех перекосов, которые тебе нужны.

Ты норкоман штоле? :D Гиги нужны клиенту. На сервере на игрока в озу потребуется примерно столько, сколько занимают сейвы на диске. Конечно, бывают игры с сейвами по несколько десятков или даже сотен метров. Но у нас же речь про MMO, а в современных MMO нет такого количества состояний, как в современном же синглплеере.

 

_DEN_, опять-таки берём офиц. инфу и прикидываем примерные цифири в среднем на юзверя..

конечно, скромненькая ммо можь и меньше метра сервачной озу на юзверя тратит

для гамисов широкий канал и аптайм 0,999 -- дело святое, а такое дёшево не найдёшь.

 

1. У нас речь о персональной онлайн-доле рама на одного юзера, а не на всю инфраструктуру вцелом. Вов при его масштабах и легаси-бремени не самый лучший пример чтобы делать выводы.

2. "World of Warcraft (WoW) is played by more than 11.5 million users across three continents" - маркетинг баллшит. Важно лишь то, сколько у них одновременно онлайн, а не насколько хорошо работает отдел продаж.

 

_DEN_, скажем так, если озу хватает / особых косяков в либах да собственном коде нет / с железками всё хоккей / пинги низкие и фатальных потерь сетевых пакетов нет / читеров да дидосеров тоже отсеяли / потоков достаточно мало ==>> любая схема синхи будет примерно равнозначна по скорости.

 

_DEN_, обычно стэйт живет в БД. Но вообще гейм-сервера - это отдельная магия. Тут я спорить не буду. По поводу тестов - конечно отпишу. Это уже близко.

 

superakira, прошу прощения за собственную лень, но не мог бы ты в двух словах объяснить, почему вообще возникла мысль попробовать заюзать фиберы в азио? Вот возьмем простой TCP echo сервер. Он представляет собой:

• 1 asio::io_service
• N working threads (io_service::run)
• 1 tcp::acceptor

Логика сервера:
1. new tcp::socket
2. async_accept
3. on_accept: async_read, го п. 1

Цикл запроса-ответа:
1. on_read: async_write
2. on_write: delete tcp::socket

Берем 100500 ботов, и отправляем их на сервер. Вопросы:

1. Почему 1 io_service лучше чем N изолированных пар io_service + working thread?
2. Где и что будет заменено на фиберы, и почему это должно быть лучше (теоретически)?

 

_DEN_, ну да ты описал классическую схему.
100500 ботов не вывозит (практика).
по п1 - предположим ты передал сокет в другой поток со своим сервисом, а там где создал его - тот поток грохнул... проблема. это пример не с потолка. ну и много можно накидать еще.
по п2 - в теории должно быть быстрее. ты как я понял ппц поленился глянуть)
http://www.boost.org/doc/libs/develop/libs/fiber/examples/asio/autoecho.cpp
собственно мне это нарвиться больше чем chains вызовов городить это во первых. Во-вторых, есть видео автора этой библы на ютубе. Там он говорит зачем почему итд (послушай, это будет полюбому развернутее чем пост на васме). Вообще работа с зелеными потоками сейчас в тренде.
Например
http://www.seastar-project.org/
Лютая тема, но только под никсы, поэтому я пока на асио.