1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Asio+Fibers

Тема в разделе "WASM.NETWORKS", создана пользователем superakira, 22 мар 2017.

  1. superakira

    superakira Guest

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

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    Дай каждому потоку свой io_service и им не понадобится синхронизация. Я кстати не помню чтобы какие-то дела с синхронизацией просаживали время. Хотя я никогда не использовал один и тот же io_service из разных потоков. Как-то раз увидел пример сервера в доках буста, там чел сделал round-robin контейнер пар поток+io_service, и выдавал их входящим подключениям. Мне это понравилось и далее я делал только на такой архитектуре.
     
  3. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    Хотя что я несу, лол. Треды io_service::run это треды обработки, а отправка заданий в любом случае должна быть синхронизирована.
     
  4. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    Поэтому на самом деле начать нужно с этого:
    Результаты тестирования есть, или это просто домысел?
     
  5. superakira

    superakira Guest

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

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    superakira, но все-таки, может попробовать архитектуру "каждому потоку свой io_service"? В таком виде операций, которым нужна синхронизация, будет гораздо меньше (одна на соединение), и может это перестанет быть проблемой. Фиберы не юзал, позырю.
     
  7. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.269
    взаимоблокировка потоков очень частая трабла.
     
  8. superakira

    superakira Guest

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

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    Ну да, у каждого потока будет своя собственная очередь. Только почему это плохо?

    Это почему?

    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-ов это плохо, со ссылкой на исходники, или хотя бы на низлежащее апи оси.
     
  10. _DEN_

    _DEN_ DEN

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

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

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.269
    по большей части всё упирается в вопрос КАКОЙ ВАРИАНТ ЖРЁТ БОЛЬШЕ ОЗУ. более прожорливый повышает вероятность свопа, а сие есмь ..опа ;D
     
  12. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    UbIvItS, в продакшене это должна быть достаточно специфичная задача и достаточно жадный хозяин, чтобы ось ушла в своп. Сервак с 256 гб озу стоит меньше 150 евро в месяц.
     
  13. UbIvItS

    UbIvItS Well-Known Member

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

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    https://www.hetzner.de/hosting/produkte_rootserver/px121

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

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

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.269
    _DEN_, опять-таки берём офиц. инфу и прикидываем примерные цифири в среднем на юзверя..
    конечно, скромненькая ммо можь и меньше метра сервачной озу на юзверя тратит :)

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

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    1. У нас речь о персональной онлайн-доле рама на одного юзера, а не на всю инфраструктуру вцелом. Вов при его масштабах и легаси-бремени не самый лучший пример чтобы делать выводы.

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

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    5.269
    _DEN_, скажем так, если озу хватает / особых косяков в либах да собственном коде нет / с железками всё хоккей / пинги низкие и фатальных потерь сетевых пакетов нет / читеров да дидосеров тоже отсеяли / потоков достаточно мало ==>> любая схема синхи будет примерно равнозначна по скорости.
     
  18. superakira

    superakira Guest

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

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.377
    Адрес:
    Йобастан
    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. Где и что будет заменено на фиберы, и почему это должно быть лучше (теоретически)?
     
    Последнее редактирование: 2 апр 2017
  20. superakira

    superakira Guest

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