Эффективный предварительный дизайн сервера с NBIO, как epoll, kqueue с использованием libevent - PullRequest
Новая
       95

Эффективный предварительный дизайн сервера с NBIO, как epoll, kqueue с использованием libevent

2 голосов
/ 21 ноября 2011

Я планирую написать сервер 'комет' для потоковой передачи данных клиентам.В прошлом я усовершенствовал один, чтобы использовать преимущества многоядерных процессоров, но теперь я начинаю с нуля.Я планирую использовать epoll / kqueue или libevent для питания сервера.

Одна из проблем, над которыми я работал, - какой дизайн сервера использовать?У меня есть несколько доступных вариантов, так как я планирую использовать многопроцессорную модель, чтобы использовать преимущества всех ядер ЦП.

  1. Предварительно разветвленный многопроцессорный процесс - каждый процесс выполняет самостоятельно, принимает
  2. Предварительно разветвленный многопроцессный процесс с мастером - главный процесс принимает, а затем использует передачу дескриптора для передачи принятого сокета процессу
  3. Предварительно разветвленный многопроцессный процесс с разными портами - каждый процесс прослушивает разныепорт в той же системе.Балансировщик нагрузки решает, какой процесс получит следующее соединение, основываясь на некоторой обратной связи по нагрузке от отдельных процессов демона.

Конструкция №2 наиболее сложна.Конструкция №3 проста, но включает в себя дополнительное оборудование, которое мне понадобится независимо от конструкции, поскольку оно будет работать на нескольких машинах и в любом случае потребует балансировщик нагрузки.Проект № 1 имеет проблему с громоподобным стадом, но я думаю, что с 8 процессами громоздкое стадо не имеет большого значения, но становится серьезным, когда клиенты постоянно подключаются и отключаются (что должно быть редко, поскольку это комет-сервер).

На мой взгляд, # 2 сложен и требует 2 дополнительных системных вызовов из-за передачи дескриптора между процессами master и slave для каждого accept.Лучше ли иметь эти накладные расходы против проблемы грома в стаде?Если у меня будет 8 процессов, которые проснутся и выполнят принятие, я потенциально смогу увидеть 8 приемов, если я использую Design # 1?

Каковы плюсы и минусы моего выбора дизайна?Что бы вы порекомендовали?

Ответы [ 2 ]

0 голосов
/ 22 ноября 2011

Если вы хотите создать очень масштабный и высокопроизводительный HTTP-демон, ни один из № 1, № 2 и № 3 не подходит. Вам лучше использовать модели 1-m-m или m-to-n с многопоточностью, если вы хотите добиться масштабируемости, как это делают nginx / lighttp.

На самом деле, если вы ожидаете, что программа будет обрабатывать менее ста соединений в секунду, то # 1, # 2 и # 3 могут не иметь никакого видимого значения.

Тем не менее, я бы пошел на №2 в случае, если вы можете расширить свою программу в будущем, переключив процесс на поток, так как он может быть легко интегрирован в модели обработки 1-m-m или m-to-n. .

0 голосов
/ 21 ноября 2011

Если бы это были не процессы, а потоки, я бы выбрал вариант 2. В любом случае, для процессов это кажется мне дорогим, поэтому мы должны выбирать между 1 и 3.

Я бы предпочел 1,можно ли как-то оценить ожидаемую нагрузку.Не могли бы вы установить верхний предел для размера спящего стада, скажем, предварительно разветвленных процессов?Как быстро вам нужно принимать новые подключения?

Так что, если вы собираетесь идти по пути Тома Дансона и быстро перенести большое стадо через Красную реку в Канзас, вам, вероятно, нужно выбрать третий путь.Так как ресурсы все равно доступны ...

...