(Обычно называется проблемой C10K)
Существует ли более современный обзор решений проблемы c10k (Последнее обновление: 2 сентября 2006 г.), в частности, ориентировано на Linux ( epoll, signalfd, eventfd, timerfd..) и библиотеки, такие как libev или libevent?
Что-то, что обсуждает все решенные и все еще нерешенные проблемы на современном Linux-сервере?
Проблема C10K обычно предполагает, что вы пытаетесь оптимизировать один сервер, но поскольку ваша ссылка на статью указывает на то, что "оборудование больше не является узким местом". Поэтому первый шаг к тому, чтобы убедиться, что это нелегко и дешевле просто выбросить больше оборудования в микс.
Если у нас есть ящик стоимостью 500 долларов США, обслуживающий X-клиентов в секунду, гораздо эффективнее всего купить еще 500 долларов США, чтобы удвоить нашу пропускную способность, а не позволить служащему сожрать, кто знает, сколько часов и долларов пытается выяснить как выжать больше из оригинальной коробки. Конечно, если предположить, что наше приложение совместимо с несколькими серверами, мы знаем, как загрузить баланс и т.д. И т.д.
Кстати, всего несколько дней назад программирование Reddit или, возможно, Hacker News упомянули эту часть:
Тысячи потоков и блокировка IO
В первые дни Java, мои друзья программирования C смеялись надо мной для создания сокета IO с блокировкой потоков; в то время альтернативы не было. В наши дни, с обильной памятью и процессорами, она представляется жизнеспособной стратегией.
Статья датируется 2008 годом, поэтому она тянет ваш горизонт на пару лет.
Чтобы ответить на вопрос OP, вы можете сказать, что сегодня эквивалентный документ касается не оптимизации одного сервера для загрузки, а оптимизации всей онлайн-службы для загрузки. С этой точки зрения количество комбинаций настолько велико, что то, что вы ищете, не является документом, это живой веб-сайт, который собирает такие архитектуры и рамки. Такой сайт существует и называется 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
Он показывает достаточное количество данных о производительности и настройках конфигурации ОС, которые он должен был выполнить, чтобы поддерживать соединения 10K и 1M.
Кажется, что система с 30 ГБ оперативной памяти может обрабатывать 1 миллион подключенных клиентов по типу симуляции в социальной сети, используя интерфейс libevent для сервера приложений на основе Erlang.
libev запускает некоторые ориентиры против себя и libevent...
Я бы рекомендовал прочитать Zed Shaw poll, epoll, science, and superpoll [1]. Почему epoll не всегда является ответом, и почему иногда даже лучше идти с опросом, и как принести лучшее из обоих миров.
Взгляните на проект RamCloud в Стэнфорде: https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud
Их целью является 1,000,000 RPC операций/сек/сервер. У них есть многочисленные контрольные показатели и комментарии к узким местам, которые присутствуют в системе, которая помешала бы им достичь своих целей пропускной способности.