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

Если вы используете nginx, то вы имеете в виду лишь несколько килобайт накладных расходов на каждое активное соединение. Если вы используете что-то вроде Apache, у вас будет один поток на каждое соединение, что означает сотни КБ или даже мегабайт на одно соединение.

Однако nginx не поддерживает асинхронный диск Ввод-вывод в Linux (поскольку асинхронный дисковый ввод-вывод в Linux ужасно нарушен конструктивно). Таким образом, вам придется запускать множество рабочих процессов nginx, поскольку каждое чтение с диска может блокировать весь рабочий процесс. Если вы используете FreeBSD, это не проблема, и nginx творит чудеса с асинхронным диском и сетевым вводом-выводом. Но вы можете придерживаться Apache, если вы используете Linux для этого проекта.

Но на самом деле самое главное - это дисковый кеш, а не выбранный вами веб-сервер. Вам нужно много свободной оперативной памяти, чтобы ОС кэшировала эти файлы и выполняла считывание очень быстро. Если «горячий набор» превышает, скажем, 8 ГБ, подумайте о том, чтобы вместо этого получить меньше оперативной памяти и недорогой твердотельный накопитель, поскольку соотношение цена / выгода, вероятно, будет лучше.

Наконец, подумайте об использовании CDN, чтобы разгрузить это, и получить действительно дешевый сервер. Они обслуживают статические файлы, и делают это очень быстро и очень дешево. SimpleCDN имеет самые низкие цены, но MaxCDN, Rackspace, Amazon и т. Д. - все они являются крупными игроками на нижнем уровне пространства CDN.

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

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

Веб-сервер добавит накладные расходы памяти для каждого клиента, но 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-alive, использование памяти G-WAN может оставаться стабильным для HTTP-запросов keep-alive, и оно растет гораздо меньше, чем для Nginx с не-keep-alived. Запросы.

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

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

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

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

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

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

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

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