В чем преимущество «одного потока на соединение» на HTTP-сервере? - PullRequest
1 голос
/ 22 ноября 2011

Если я программировал HTTP-сервер, почему я должен рассматривать обработку каждого HTTP-соединения в своем собственном потоке?

Я прочитал множество аргументов о том, что управляемые событиями HTTP-серверы быстрее и более масштабируемы, чем потокиз них.(Например, см. Ars Technica на Nginx ).И все же Apache, самый популярный сервер в мире, работает с потоками.Зачем?Каковы преимущества?

1 Ответ

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

Код просто против.

По сути, без языковой поддержки (такой как C # и VB будут доступны в следующих версиях) и действительно хороших библиотек, написание асинхронного кода будет сложно. Не исключено, и, несомненно, будут комментарии тех, кто может это сделать, стоя на голове, но это сложнее, чем синхронная версия. Нам гораздо лучше думать о коде, который просто выполняется сверху вниз, чем о коде, который должен быть реентерабельным и т. Д.

В зависимости от вашей платформы, потоки могут быть вполне дешевыми в наши дни - поэтому при соответствующем пуле модель потока на запрос работает очень хорошо для серверов, которые не нуждаются обрабатывать , что много запросов одновременно. Конечно, это отстой для длинных опросов или серверов, которым в основном нужно делегировать запросы другим службам, для возврата которых может потребоваться «некоторое время» (даже если это всего лишь одна десятая секунды). Последний класс сервера должен иметь возможность обрабатывать огромные скорости запросов, поскольку они выполняют только минимальную обработку для выполнения своей работы - но если они затягивают поток для каждого запроса, просто блокируют, ожидая, пока другая служба вернись, это может быть очень расточительным, особенно памяти.

...