Разработка веб-сервера, на котором размещается смешанный статический контент малого и большого размера (более 100 МБ).

Я не ожидал, что в этом случае будет большая разница, если таковая имеется, между Apache/Nginx/Lighttpd. Я ожидаю, что Apache будет немного больше загружать память, если вы урежете все модули, которые вам не нужны (что, вероятно, большинство из них). Мой личный выбор был бы Lighttpd просто потому, что я более знаком с ним для обслуживания статических файлов, и у меня никогда не было проблем с ним, несмотря на относительно высокую нагрузку на него.

Что касается вопроса о кешировании ОЗУ... ОС должна делать это автоматически, если у вас достаточно ОЗУ. Вы можете проверить это, рассчитав время, необходимое для получения N разных файлов, по сравнению с получением одного и того же файла N раз, хотя различий может и не быть. Учитывая, что ваши файлы относительно большие, я определенно не стал бы экономить на оперативной памяти вашего сервера, если у вас есть выбор. Скорее всего, в вашем случае вы будете ограничены пропускной способностью сети прежде всего.

Как и во многих вопросах такого типа, лучший ответ - это тестирование, тестирование и тестирование еще. Довольно легко получить все три настройки на одном сервере (под разными портами), а затем выполнить базовый сравнительный анализ с помощью такого инструмента, как ApacheBench (ab, поставляется с Apache) или чего-то подобного. Проверьте загрузку / использование памяти вашего сервера, сравните доступные частоты запросов и посмотрите, какой из них лучше всего подходит для вашей ситуации.

Этот вопрос пахнет преждевременной оптимизацией.

Я надеялся, что будет что-то, что поймет, что один файл пользуется большим спросом, например, когда выйдет новый эпизод, и поместит его в кэш ОЗУ. Можно ли использовать NGINX таким образом?

Об этом вам даже не нужно беспокоиться - он будет кэшироваться ОС и помещаться в ОЗУ при первом запросе. Он останется в оперативной памяти, так как все будут просить об этом.

Настройте что-нибудь простое и легкое (apache/nginx) и позвольте ему разорваться.

Если вам нужна помощь в обслуживании данных (особенно если учесть, что на сервере недостаточно ОЗУ для кэширования), сначала поместите CDN (т. Е. Cloudflare). На самом деле, поскольку у Cloudflare есть бесплатный уровень, поставьте его на передний план!

Примерно у вас есть следующие варианты:

1. Продолжайте делать то, что вы делали раньше, но увеличьте свою пропускную способность, перейдя на более крупный план хостинга.
2. Получите сервер с выделенной неограниченной восходящей линией связи 100/1000/10000 Мбит, позволяющей вам перейти от универсального хостингового решения к чему-то более индивидуальному для вашего варианта использования.
3. Разгрузите ваши требования вещания к сети доставки контента (CDN). Это означает, что вы, вероятно, можете остаться в текущем плане хостинга, потому что большая часть трафика будет обслуживаться CDN, и у вас также нет никаких изменений в вашем рабочем процессе.

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

Второй вариант не обязательно самый дешевый, но он дает вам большую гибкость, если вы можете позволить себе потратить время на приобретение необходимых навыков и тестирование предложенных (программных) конфигураций. Обычно самые быстрые данные поступают из памяти, тогда SSD, SAS и SATA-диски отстают, но также являются самым дешевым хранилищем. То, что кэширует наиболее популярные / текущие файлы в памяти, должно быть самым быстрым (например, Varnish), хотя Linux в любом случае обычно использует любую неиспользуемую память в качестве дискового кеша, и любого легковесного веб-сервера должно хватить для статического содержимого.

Даже если вы не используете бесплатный CDN, такой как cloudflare, CDN может сработать намного дешевле, чем варианты 1 и 2.