Есть ли любой современный обзор решений 10 000 проблем клиента/секунда

Так совпало, что всего несколько дней назад Programming Reddit или, может быть, Hacker News упомянули эту статью:

Тысячи потоков и блокировка IO

В первые дни Java мои друзья по программированию на C смеялись надо мной за то, что я делал socket IO с блокировкой потоков; в то время альтернативы не было. В наши дни, с обильной памятью и процессорами, это кажется жизнеспособной стратегией.

Статья датирована 2008 годом, поэтому она тянет ваш горизонт вверх на пару лет.

libev выполняет несколько тестов против себя и libevent ...

Я бы порекомендовал прочитать опрос Зеда Шоу , epoll, science и superpoll [1]. Почему epoll - не всегда ответ, и почему иногда даже лучше пойти с опросом, и как объединить лучшее из обоих миров.

[1] http://sheddingbikes.com/posts/1280829388.html

Взгляните на проект RamCloud в Стэнфорде: https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud

Их цель - 1 000 000 операций RPC в секунду на сервер. У них есть многочисленные тесты и комментарии к узким местам в системе, которые могут помешать им достичь своих целей по пропускной способности.

Чтобы ответить на вопрос OP, вы могли бы сказать, что сегодня эквивалентный документ не об оптимизации единый сервер для нагрузки, но оптимизирующий под нагрузку весь ваш онлайн-сервис. С этой точки зрения количество комбинаций настолько велико, что то, что вы ищете, не является документом, это живой веб-сайт, на котором собраны такие архитектуры и фреймворки. Такой веб-сайт существует и называется www.highscalability.com

Боковое примечание 1:

Я бы возражал против убеждения, что добавление большего количества оборудования к нему - долгосрочное решение:

• Возможно, стоимость инженера, который «получает» производительность, высока по сравнению со стоимостью одного сервера. Что происходит при горизонтальном масштабировании? Допустим, у вас 100 серверов. Увеличение емкости серверов на 10 процентов может сэкономить вам 10 серверов в месяц.

• Даже если у вас всего две машины, вам все равно придется справляться с резкими скачками производительности. Разница между сервисом, который постепенно деградирует под нагрузкой, и сервисом, который выходит из строя, заключается в том, что кто-то потратил время на оптимизацию для сценария загрузки.

Примечание 2:

Тема этого сообщения вводит в заблуждение. Документ CK10 не пытается решить проблему 10k клиентов в секунду. (Число клиентов в секунду не имеет значения, если вы также не определите рабочую нагрузку вместе с устойчивой пропускной способностью при ограниченной задержке. Думаю, Дэн Кегель знал об этом, когда писал этот документ.). Вместо этого смотрите на него как на сборник подходов к созданию параллельных серверов и микротестов для них. Возможно, с тех пор и сейчас изменилось то, что в какой-то момент можно было предположить, что услуга предназначена для веб-сайта, обслуживающего статические страницы. Сегодня сервис может быть хранилищем данных noSQL, кешем, прокси-сервером или одним из сотен программных компонентов сетевой инфраструктуры.

Проблема C10K обычно предполагает, что вы пытаетесь оптимизировать отдельный сервер, но, как указывается в вашей статье, «оборудование больше не является узким местом». Следовательно, первый шаг, который необходимо сделать, - убедиться, что просто добавить в микс больше оборудования не проще и дешевле.

Если у нас есть коробка за 500 долларов, обслуживающая X клиентов в секунду, гораздо эффективнее просто купить еще одну коробку за 500 долларов, чтобы удвоить нашу пропускную способность, вместо того, чтобы позволить сотруднику сожрать, который знает, сколько часов и долларов пытается вычислить как выжать больше из оригинальной коробки. Конечно, при условии, что наше приложение совместимо с несколькими серверами, что мы умеем балансировать нагрузку и т. Д. И т. Д.