Итак, имеем около 5 тысяч клиентов, которые висят на сервере через TCP. Изначально все было построено на модели 1 клиент - 1 поток, что уже не целесообразно. Поэтому хотелось бы узнать как на крупных серверах решают проблему:
1. Какая-то супер библиотека.
2. Асинхронные сокеты через select и затем перебор всех активных соединений if (FD_ISSET(..., ...)). Не так уж сложно перебирать 5 тысяч элементов и проверять установлен ли флаг, но это приходится делать без остановки - большой поток данных. Да и необходимо другие задачи выполнять.
3. Какая-то возможность получить только те соединения, на которых появились данные.

асинхронные сокеты + epoll()

не путайте понятия "асинхронный" и мультиплексируемый ;)
по сабжу C10k

Статья хорошая, но в ней ни к одному идеальному варианту автор не приходит. Насколько я понимаю, есть хорошие способы, чтобы решить проблему, и сделать код переносимым, но зачем описывать все способы?

однопоточное приложение всегда быстрее многопоточного.
в структуре fd_set хранится набор битов где номер бита равен номеру сокета
(4 бит равен 1, значит в сокете 4 пришло сообщение)
Если проверять на наличие сообщений по 4 байта, если есть то в этих 4 по 2, по одному потом по битам.
Выдерживает нагрузку 10к без проблем и еще куча всего остального вертится.

Это сообщение отредактировал(а) Enelar - 25.6.2010, 06:11

Серьезно?

а в Intel'е не знают. делают 8-ми, 16-ти ядерные процессоры ...

смотря как масштабируется задача
имхо, на мой взгляд, самая масштабируемая стратегия - 1 поток, слушающий сокет и N рабочих потоков каждый со своим epoll

libevent, boost::asio
;)

REZiaMIX, 
это инструменты, тут же речь про стратегии

Я говорил именно про данную задачу.

Извиняюсь за некропостинг, но как многоядерная архитекура "ускоряет" многопоточное приложение? Имеется в виду определённое автоматическое масштабирование системой, компилятором(нужное подчеркнуть) потоков на CPU core?
ЗЫ. Говорю именно про потоки, а не нити, процессы и т.п. И да, не подразумевается использование никакого API для параллельных вычислений(OpenMP etc.)

каждый поток может работать параллельно с другими занимая одно из ядер cpu
т. е. если cpu 16-ти ядерный, то, упрощая, 16 потоков будут работать параллельно

А кто же тогда 'потоки'? ('поток', он же thread, он же 'нить')

В винде fiber и thread имеют отличия. В *nix действительно, разницы нет. Однако мой вопрос был задан отнюдь не в контексте какой-либо конкретной ОС. 
Повторюсь, кто и где встречал в спецификации от hardware/software вендоров что-нибудь типа one thread-one core? Меня серьёзно интересует эта тема, ничего конкретного я пока сам не нарыл. Восновном "должно быть лучше", "теоретически", "опыты показали"...

Нету таких пока. Вендоры нацелились на многокоровость, т.к. на пути повышения тактовой частоты и архитектурного ускорения одно-потокового кода уже практически уперлись в стену  Дальнейшее увеличение производительности потребует каких то революционных изменений в архитектуре (или вообще новых архитектур), а вот этого то как раз вендоры делать и не хотят, т.к. уже наелись 'революций' (безуспешных)   

Ну я собственно что хотел сказать своим вопросом. Встречался неоднократно с мнением, что якобы многопоточное приложение более пропорционально масштабируется на многоядерной(НЕ многопроцессорной!!!) системе, нежели однопоточное.
Ради интереса провёл много тестов, и не нашёл подтверждения этому предположению. Скажем так, всё было скорее всего наоборот.
Понятное дело, что потоки нужны. Тот же epoll крайне рекомендуется делать в отдельном потоке. Как уже писали в этой теме, правильно надо масштабировать задачи. А то что чрезмерное увлечение(применять всегда и везде где только можно) потоками - неистребимое зло, сказано было уже давно и неоднократно.

Разницы между многоядерной (действительно многоядерной, а не просто HyperThread'инговой!) и многопроцессорной системой быть не должно. Разница между ними чисто количественная (типа размеров и принадлежностей кэшей, задержки на их синхронизацию и пр). И настоящее многопоточное приложение действительно будет масштабироваться.
Каких тестов? Приложение должно быть не просто многопоточным, но все его  потоки должны одновременно что то вычислять. Таких задач не так уж и много, а в быту их вообще нет. В основном это всякие CAD'ы, связанные с матричными (и подобными) расчетами. Например - обработка видео, трассировка плат и FPGA, тепловые расчеты, механические расчеты, 3D моделирование.

Это не те потоки, где будет заметен выигрыш от многокоровости/многопроцессорности. Потоки должны работать, а не ждать

Угу, несомненно. 

Позволю не согласиться. В многопроцессорной конфигурации однопоточное приложение не будет гарантировано задействовать все процессоры. Многопоточное - также. Для этого и созданы специальное API, компиляторы. С многоядерным процессором немного иначе. Тут нельзя однозначно определить как и по какому принципу нагрузка будет масштабирована на ядра.


Оно будет масштабироваться примерно также как и однопоточное. Хотя возможны вариации. 


Что подразумевается под "в быту"? Вот реальный пример. Сервер для онлайн-игры. Имеется множество равнозначных игровых сессий. В каждой просчёт игрового своего мини-мира, физика, логика и т.п. Каждая сессия активна, т.е. не ждёт, а что-то вычисляет. Второй вариант, имеется совокупность зон-локаций. В каждой выполняется просчёт мира, мобов и т.д. Как видите, очень напрашивается идея организовать каждую сущность в отдельном потоке. 
Не буду приводить примеры из области параллельных вычислений. Их там достаточно. И классическая многопоточность там не используется.


Выигрыш от потоков, на мой взгляд, это исключительно выигрыш за счёт более рационального использования effective work time. Т.е. в основном это параллельное выполнение какой-либо задачи со своими нюансами основанными на времени выполнения. Сам поток никаким образом не "ускорит" программу, и отличное(от однопотоного приложения) масштабирование потоков на разные ядра-процессоры, как мне кажется, это необоснованный миф.

пожалуй, соглашусь


а вот тут... в linux, честно говоря, не знаю, а windows сама распределяет нагрузку по процессорам/ядрам, так что пруф-линк, пожалуйста. 

Я бы даже сказал - гарантированно не будет
Будет
API - да, а компиляторы можно и обычные использовать. А можно и специальные расширения использовать. 
С точки зрения API да и вообще доступной для программиста архитектуры системы система с многоядерным процессором НИЧЕМ НЕ ОТЛИЧАЕТСЯ от многопроцессорной системы. 
Без вариантов. Должно масштабироваться. Иначе оно криво написано   
При современных мощностях процессоров сессии скорее всего будут ждать действий игроков. Вычисления будут занимать немного времени.
Аналогично.
Есть простой тест - берем однокоровый/однопроцессорный вариант, запускаем тестируемую прогу. Смотрим загрузку процессора - если она не 100%, то распараллеливать тут нечего.
Потом берем многокоровый/многопроцессорный сервер. Запускаем, смотрим загрузку - если она не 100% по всем корам, то налицо недоиспользование ресурсов, т.е. криво распараллелено (либо нужна большая нагрузка - больше клиентов или подобное).
Если все ок, сравниваем скорость работы. Должна повысится пропорционально количеству коров/процессоров
Дык, а кто не дает ее использовать? Разумеется, что бы программа работала быстрее на многокоровой машине она должна быть грамотно написана. Простое однопоточное приложение не станет работать быстрее на многокоровой машине.

Это немного другой аспект использования потоков - для упрощения логической структуры программы. Ускорения здесь не будет
В общем да.
А мне кажется, что вы не в курсе, что такое многоядерные процессоры   По сути это несколько независимых процессоров, собранных на одном кристалле. И на них потоки отличным образом ложатся. 
Термин 'масштабируются потоки' тут несколько неуместен, масштабировать можно все приложение целиком, путем создания в нем стольких потоков, сколько есть процессоров. Тогда будет достигнута максимальная производительность и загрузка аппаратуры.

я даже больше скажу
на программном уровне даже на уровне ядра будет обычное представление cpu0, cpu1, cpu2, ...
и не суть важно, cpu0 - это процессор или физическое ядро, или логическое ядро (hyper threading)