все. Я пытаюсь найти лучший способ обработки больших объемов параллельных соединений (более 800k) наилучшим образом. Я решил пойти с libevent для обработки чтения/записи в сокетах и будет использовать один порт на задней панели и передать fd на неблокирующие сокеты. Где моя проблема (ы) входят в игру:Threading, циклы событий и большое количество соединений и параллелизма
1) libevent по отношению к базам событий - если бы я был, для экземпляров, запускать один поток на каждый ядро, каждый со своей собственной базой libevent, прослушивающей один fd для входящие соединения, как бы libevent обрабатывать несколько баз событий, которые запускаются на этом одиночном fd? Идея заключалась бы в том, чтобы затем принять это входящее соединение, принять его и запустить новую базу событий на новом fd, относящемся к этому соединению. Или, это подходящий способ сделать это, как и в прошлом, - запустить основную базу событий в главном потоке программы и нажать входящее соединение на рабочий поток для обработки accept, а затем создать новую базу событий для каждого соединение тогда?
2) Нитки на соединение ... Да или нет? В прошлых реализациях я сделал модель потоков 1: 1 для принятого соединения. Конечный результат, очевидно, связан с 500 клиентами, 500 потоками и любыми потоками, которые я использовал в качестве рабочей очереди. Тем не менее, я обеспокоен тем, что это может создать проблему, когда я дойду до сотен тысяч подключений к марке ... Может ли кто-нибудь подтвердить? Я также чувствую, что многие потоки при использовании чего-то с асинхронным IO, такие как libevent, не нужны и просто добавляют дополнительные накладные расходы, чем то, что необходимо ... Но я мог ошибаться.
Это первый раз, когда мне нужно написать что-то, что поддержит этот максимум нагрузки пользователя, и я бы предпочел написать его с нуля из прочного концептуального дизайна в качестве средства полного понимания все в игре. Очевидно, я мог бы прорыть что-то вроде UnrealIRCD или исходного кода nginx и придумать решение, но я бы предпочел сделать это из понимания того, что я пишу, и почему я пишу его таким образом. Поэтому некоторые отзывы были бы весьма признательны.
Вы почти наверняка столкнетесь с проблемами, если попытаетесь запустить потоки 800k; вы можете использовать тест, чтобы это доказать. Общая идея заключается в том, что вы должны получить количество потоков от количества ядер процессора, доступных для вашей программы, чтобы снизить затраты на выделение контекстов на поток и переключение контекстов между ядрами. Многопоточность - это оптимизация, и, как и многие другие оптимизации, если вы примете это к крайности, вы не только потеряете выгоду, но и будете избегать других оптимизаций. Напишите свою программу, чтобы сначала использовать одну нить, а затем масштабировать ее ... – Sebivor
Кроме того, три самых мудрых слова, которые я могу дать, следующие: Используйте профилировщик ... – Sebivor