Я разрабатываю сетевой сервис, в котором клиенты подключаются и остаются на связи - модель недалеко от IRC, если не считать соединений s2s.
Мне может понадобиться некоторая помощь в понимании того, как выполнять планирование емкости, в частности, с учетом стоимости системных ресурсов, связанных с обработкой сообщений от / к клиентам.
Есть статья, в которой пытались подключить 1 миллион клиентов к одному серверу [1]. Конечно, большинство этих клиентов полностью простаивали во время теста. Если бы клиенты отправляли сообщение каждые 5 секунд или около того, система наверняка была бы поставлена на колени.
Но ... Как вы меньше машете руками и знаете, мера такой переломный момент?
Мы говорим о сообщениях, отправляемых клиентом через сокет TCP в ядро и считываемых приложением. Данные перетасовываются в памяти из одного буфера в другой. Нужно ли учитывать пропускную способность памяти («5 ГТ / с» [2] и т. Д.)?
Я почти уверен, что у меня есть возможность измерить основные требования к памяти из-за буферов TCP / IP, ожидаемой пропускной способности и ресурсов ЦП, необходимых для обработки сообщений. Я немного смущен тем, что называю «мыслительным».
Помогите!
Кроме того, кто-нибудь действительно так делает? Или большинство людей машут рукой и видят, что предлагает реальный мир, а затем реагируют соответствующим образом?
[1] http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3/
Мы говорим о сообщениях, отправляемых клиентом через сокет TCP в ядро и считываемых приложением. Данные перетасовываются в памяти из одного буфера в другой.
Нет, это не так. Нет, если вы все равно сделаете это правильно. Для Linux вы должны найти системные вызовы sendfile (2) и splice (2). Другие ядра, вероятно, имеют аналогичные средства нулевого копирования, но, как ни странно, они не стандартизированы.
На практике лучше писать программу как можно проще, измерять, где находится узкое место, улучшать, измерять, улучшать ... Предсказать узкие места сложно, и преждевременная оптимизация является корнем всех зол (как сказал Кнут).