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