Сколько оперативной памяти для обслуживания тяжелого статического контента?

Если операционная система может кэшировать горячую часть контента в оперативную память, она не будет использовать диск и будет обслуживать ее очень быстро. На VPS должны быть возможны сотни запросов в секунду, вы, скорее всего, будете насыщать сеть задолго до того, как перейдете в пределы загрузки ЦП.

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

Веб-сервер добавляет накладные расходы памяти на клиента, но nginx может сделать это за несколько килобайт на соединение.

Надеюсь, что эти указатели могут помочь вам.

какие ресурсы нужны для обслуживания статического контента? Сколько оперативной памяти используется для каждой передачи файла?

Во-первых, для того же числа рабочих G-WAN v4.7+ использует гораздо меньше оперативной памяти, чем Nginx при запуске:

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:21228 Process RAM: 0.77 MB
  5] pid:21229 Process RAM: 2.44 MB
  4] pid:21230 Process RAM: 2.44 MB
  3] pid:21231 Process RAM: 2.44 MB
  2] pid:21232 Process RAM: 2.44 MB
  1] pid:21233 Process RAM: 2.44 MB
  0] pid:21234 Process RAM: 2.44 MB
---------------------------------------------
Total 'nginx' server footprint: 15.39 MB

> Server 'gwan' process topology:
---------------------------------------------
  6] pid:6054 Thread
  5] pid:6053 Thread
  4] pid:6052 Thread
  3] pid:6051 Thread
  2] pid:6050 Thread
  1] pid:6049 Thread
  0] pid:5839 Process RAM: 2.19 MB
---------------------------------------------
Total 'gwan' server footprint: 2.19 MB

G-WAN использует потоки (обычно по одному на ядро), Nginx использует процессы (обычно по одному на ядро), и процессы тянут больше ресурсов, требуют синхронизации через общую память и т. Д. Оба используют "асинхронную" модель обработки событий.

Обратите внимание, что здесь G-WAN может автоматически увеличиваться до более чем 1 миллиона одновременных соединений, в то время как Nginx ограничен его worker_connections настройки (определены только в 4096 в тесте ab.c выше).

что мне не понятно, так это то, что на каждое соединение накладывается дополнительная память: то есть, если nginx или gwan потребляют память для каждого удара?

Коротко говоря, G-WAN v4.7+ (где кэширование в памяти отключено по умолчанию) потребляет намного меньше оперативной памяти, чем Nginx, для файлов всех размеров, одновременно обслуживая больше запросов в секунду.

Длинная история состоит в том, что, хотя Nginx потребляет все больше и больше памяти даже с новыми HTTP-запросами keep-alived, использование памяти G-WAN может оставаться стабильным для HTTP-запросов keep-alived, и оно растет гораздо меньше, чем для Nginx с non-keep-alived Запросы.

Наша оболочка weighttp ab.c измеряет потребление памяти серверным приложением и системой на время теста. И это показывает, что Nginx увеличивает нагрузку на систему в отношении потребления ресурсов памяти.

Это связано с тем, как каждый веб-сервер обрабатывает запросы и выделяет память.

Если у меня одновременно будет 10 запросов на файл 5 МБ, будет ли это означать, что для его обслуживания будет использовано 50 МБ памяти? Может быть, + память для потоков (я не знаю, использует ли nginx или gwan темы для evey-соединения).

Оба сервера (Nginx и G-WAN) используют sendfile() поэтому ядро ​​(а не приложение) выделяет ресурсы для ввода / вывода.

Веб-серверы по-прежнему будут распределять ресурсы, но это для поддержания контекста каждого соединения, а не для буферизации дискового ввода-вывода.

Таким образом, потребление памяти зависит от размера файловых фрагментов, отправляемых на каждый sendfile() звоните, а не прямо на общий размер файла.

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

Есть еще вопросы, напишите нам на G-WAN. Мы вложили значительные средства в CDN-подобные приложения.