2016-05-03 4 views
1

Я столкнулся с этим вопросом в блоге. Это было задано Mozilla в интервью для интернатуры. (Blog Post)Использование ресурсов статического веб-сервера

Вы работаете с HTTP-сервера (Nginx, Apache и т.д.), который настроен обслуживать статические файлы из локальной файловой системы вашего современного, многоядерного сервера, подключенного к гигабитной сети. Несколько клиентов начинают запрашивать один и тот же статический файл 4kb так быстро, как только могут. Какой системный ресурс , по вашему мнению, будет исчерпан первым?

a. CPU
б. Диск/ввод/вывод
c. Память
d. Сеть
e. Прочее

По моему мнению, ничто из этого не будет исчерпано на современной машине с Nginx/Apache. Не будет ли веб-сервер кэшировать такой небольшой файл и просто будет обслуживать его. Кроме того, для повторного запроса он может легко отправить Not-Modified заголовок.

В случае Apache, я думаю, из-за того, что он обрабатывает несколько клиентов путем нереста потоков, CPU будет исчерпан первым, но для «горстки» клиентов это не имеет значения.

Я хотел знать, что другие могут сказать об этом вопросе.

+1

Сеть, затем ЦП. – ardhitama

ответ

1

Это зависит от времени. 4k - это магический размер, который будет соответствовать всем кешам и буферам по умолчанию, так что легко и быстро пройти. память здесь не является ограничивающим фактором, поскольку веб-серверы будут работать с файловыми дескрипторами, а не целыми файлами. В этом случае я бы предположил, что они сохраняют это правильно в памяти, но это будет один файл на рабочий экземпляр, который, как правило, доходит до 4kb * (num_cores + 1) максимум, что на самом деле не проблема.

Можно утверждать, что проблема с памятью или диском была проблемой. Но прежняя была неактивна, когда методы, подобные , были правильно настроены, что позволило использовать подход с нулевой копией. Последний будет амортизироваться со временем, как только копия файла будет загружена в память.

Наконец, есть интерфейс и процессор (ы). В целом, время процессора, как правило, намного дешевле, чем время в сети, поэтому я ожидаю, что NIC будет узким местом задолго до CPU - если вообще.

Вопрос немного не определен для местоположения клиентов. Если они подключены к одной и той же сети GbE, у них действительно есть возможность насытить ваш сетевой адаптер своими запросами. Если нет, некоторым посредником может стать ограничивающий фактор.

Теперь предположим, что эти клиенты были в нашей сети, и здесь у нас был одножильный сетевой адаптер 10GbE, подключенный через 8 дорожек (что довольно стандартно IMHO): PCIe 3.0 x8 задан с 7 877 МБ/с. A Core i7 3770 имеет скорость шины 5 Гбит/с, что составляет примерно 8 ГБ/с на 8 полосах. Предполагая, что никакая другая интенсивная загрузка ввода-вывода не будет выполнена, этот процессор может легко насытить сетевой адаптер.

Итак, вкратце: насыщенность сети/сетевого адаптера перед насыщением CPU перед чем-либо еще.

+0

Будет ли сеть насыщаться из-за HTTP-накладных расходов? Я предполагаю, что через некоторое время сервер начнет отправлять Not-Modified ответ для клиентов, запрашивающих один и тот же файл снова и снова, но даже для этого потребуется HTTP-ответ. –

+0

Нет, я предполагал сырое движение. 304 потребует, чтобы клиенты были достаточно умны, чтобы отправлять заголовки 'If-None-Match' или' If-Modified-Since', которые, как я чувствовал, были не в духе вопроса. Я думаю, что в основном это максимальная пропускная способность без каких-либо функций протокола приложения. Кроме того, NIC все еще может быть насыщен 304 ответами. – DaSourcerer

Смежные вопросы