Существует ли какой-либо современный обзор решений проблемы 10000 клиент / сек?
(Обычно называется проблемой C10K)
Существует ли более современный обзор решений проблемы c10k (Последнее обновление: 2 сентября 2006 г.), специально посвященный Linux (epoll, signalfd, eventfd, timerfd..) и таким библиотекам, как libev или libevent?
Что-то, что обсуждает все решенные и все еще нерешенные проблемы на современном сервере Linux?
7 ответов
Проблема C10K обычно предполагает, что вы пытаетесь оптимизировать один сервер, но, как указывается в вашей ссылочной статье, "оборудование больше не является узким местом". Поэтому, первый шаг, который нужно сделать, это убедиться, что это не самый простой и дешевый способ - просто добавить больше оборудования.
Если у нас есть коробка стоимостью 500 долларов, обслуживающая X клиентов в секунду, гораздо эффективнее просто купить другую коробку стоимостью 500 долларов, чтобы удвоить нашу пропускную способность, вместо того, чтобы позволить сотруднику сгорбиться, который знает, сколько часов и долларов пытается выяснить, как сжать больше из оригинальной коробки. Конечно, это предполагает, что наше приложение совместимо с несколькими серверами, что мы знаем, как балансировать нагрузку и т. Д., И т. Д.
По совпадению, всего несколько дней назад, программирование Reddit или, возможно, Hacker News упомянул эту часть:
Тысячи потоков и блокировка ввода-вывода
В первые дни Java мои друзья по программированию на C смеялись надо мной за то, что я выполнял сокет IO с блокирующими потоками; в то время альтернативы не было. В наши дни с обильной памятью и процессорами это представляется жизнеспособной стратегией.
Статья датирована 2008 годом, поэтому она на несколько лет расширяет ваш кругозор.
Чтобы ответить на вопрос OP, вы можете сказать, что сегодня эквивалентный документ посвящен не оптимизации нагрузки на один сервер, а оптимизации всего вашего онлайн-сервиса под нагрузку. С этой точки зрения, количество комбинаций настолько велико, что вы ищете не документ, а живой веб-сайт, на котором собраны такие архитектуры и структуры. Такой веб-сайт существует и называется http://www.highscalability.com/
Примечание к стороне 1:
Я бы поспорил с верой, что использование большего количества оборудования - это долгосрочное решение:
Возможно, стоимость инженера, который "получает" производительность, высока по сравнению со стоимостью одного сервера. Что происходит, когда вы уменьшаете масштаб? Допустим, у вас есть 100 серверов. 10-процентное улучшение производительности серверов может сэкономить вам 10 серверов в месяц.
Даже если у вас всего две машины, вам все равно придется справляться с резкими скачками производительности. Разница между сервисом, который постепенно изнашивается под нагрузкой, и сервисом, который выходит из строя, состоит в том, что кто-то потратил время на оптимизацию для сценария загрузки.
Примечание 2:
Тема этого поста немного вводит в заблуждение. Документ CK10 не пытается решить проблему 10 тыс. Клиентов в секунду. (Число клиентов в секунду не имеет значения, если вы не определяете рабочую нагрузку наряду с устойчивой пропускной способностью при ограниченной задержке. Я думаю, что Дэн Кегель знал об этом, когда писал этот документ.). Взгляните на это как на сборник подходов к созданию параллельных серверов и микропроцессоров для них. Возможно, что изменилось с того времени до настоящего момента, так это то, что в какой-то момент вы могли предположить, что сервис предназначен для веб-сайта, который обслуживает статические страницы. Сегодня сервис может быть хранилищем данных NoSQL, кешем, прокси или одной из сотен частей программного обеспечения сетевой инфраструктуры.
Вы также можете взглянуть на эту серию статей:
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3
Он показывает достаточное количество данных о производительности и работу по настройке ОС, которую он должен был выполнить для поддержки соединений 10К, а затем 1М.
Похоже, что система с 30 ГБ ОЗУ могла бы обрабатывать 1 миллион подключенных клиентов в симуляторе типа социальной сети, используя свободный интерфейс к серверу приложений на основе Erlang.
Посмотрите на проект RamCloud в Стэнфорде: https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud
Их цель - 1 000 000 операций RPC / сек / сервер. У них есть многочисленные тесты и комментарии по поводу узких мест, присутствующих в системе, которые не позволяют им достичь своих целей по пропускной способности.
Я бы порекомендовал читать Зед Шоу poll, epoll, science, and superpoll[1]. Почему epoll не всегда является ответом, и почему иногда даже лучше пойти с опросом, и как собрать лучшее из обоих миров.