Архитектура веб-сервера, на котором размещается смешанный малый и большой (100 МБ +) статический контент [закрыто]
У меня есть задача разместить около 200-1000 mp3-файлов, все размером более 100 МБ.
Кроме того, есть несколько небольших файлов RSS и файлов JPG меньшего размера.
Все это статическое содержимое, без PHP или каких-либо сценариев. Также не будет HTML-хостинга, ничего не должно быть HTTPS, никакие пользовательские данные не хранятся на сервере.
Эти файлы являются подкастами, не защищенными авторскими правами, которые созданы нами и доступны для бесплатного скачивания на itunes и везде, и их можно найти с помощью rss.
До недавнего времени эти файлы размещались на дешевом хостинге у godaddy, но из-за огромного трафика у нас нет другого выхода, кроме как разместить эти файлы где-нибудь в другом месте.
Раньше я использовал Apache только для всех моих нужд хостинга, но у меня есть подозрение, что apache не будет идеальным решением для этих требований, и потому что сервер работает немного медленнее и не имеет этого много оперативной памяти, мне интересно, подойдет ли другой сервер для этих требований.
Какой сервер вы порекомендуете? Я надеялся, что будет что-то, что поймет, что один файл пользуется большим спросом, например, когда выходит новый эпизод, и поместит его в кэш ОЗУ.Можно ли таким образом использовать NGINX? Следует ли мне использовать Lighthttpd?
Я бы не ожидал, что в этом случае будет большая разница между Apache / Nginx / Lighttpd. Я бы ожидал, что Apache будет немного тяжелее с памятью, если вы урежете все модули, которые вам не нужны (а это, вероятно, большинство из них). Лично я выбрал бы Lighttpd просто потому, что я больше знаком с ним для обслуживания статических файлов, и у меня никогда не возникало проблем с ним, несмотря на относительно высокие нагрузки на него.
Что касается вопроса кэширования ОЗУ ... ОС должна сделайте это автоматически, если у вас достаточно оперативной памяти. Вы можете проверить это, подсчитав, сколько времени потребуется для получения N разных файлов по сравнению с получением одного и того же файла N раз, хотя большой разницы может не быть. Видя, что ваши файлы относительно большие, я бы определенно не стал экономить на оперативной памяти вашего сервера, если у вас есть выбор. Скорее всего, в вашем случае вы будете ограничены пропускной способностью сети прежде всего.
Как и на многие вопросы этого типа, лучшим ответом является тест , тест и протестируем еще . Довольно легко настроить все три сервера на одном сервере (с разными портами), а затем провести базовый тест с помощью такого инструмента, как ApacheBench (ab, поставляется с Apache) или чего-то подобного. Проверьте загрузку вашего сервера / использование памяти, сравните доступные скорости запросов и посмотрите, какой из них лучше всего подходит для вашей ситуации.
Довольно легко настроить все три сервера на одном сервере (под разными портами), а затем провести базовый тест с помощью такого инструмента, как ApacheBench (ab, поставляется с Apache) или чего-то подобного. Проверьте загрузку сервера / использование памяти, сравните доступные скорости запросов и посмотрите, какой из них лучше всего подходит для вашей ситуации. Довольно легко настроить все три сервера на одном сервере (под разными портами), а затем провести базовый тест с помощью такого инструмента, как ApacheBench (ab, поставляется с Apache) или чего-то подобного. Проверьте загрузку сервера / использование памяти, сравните доступные скорости запросов и посмотрите, какой из них лучше всего подходит для вашей ситуации.Этот вопрос пахнет преждевременной оптимизацией.
Я надеялся, что будет что-то такое, что поймет, что один файл пользуется большим спросом, например, когда выходит новый эпизод, и поместит это в кеше RAM. Можно ли использовать NGINX таким образом?
Вам даже не о чем беспокоиться - он будет кэширован ОС и помещен в ОЗУ при первом запросе. Он останется в ОЗУ, так как все будут его запрашивать.
Настройте что-нибудь простое и легкое (apache / nginx) и позвольте ему копировать.
Если вам нужна помощь в обслуживании данных (особенно с учетом того, что сервер не имеет много ОЗУ для кеша) поместите CDN (например, Cloudflare) впереди. На самом деле, поскольку Cloudflare имеет уровень бесплатного пользования , поставьте его вперед!
Примерно у вас есть следующие варианты:
- Продолжайте то, что вы делали раньше, но увеличьте свою собственную пропускную способность, перейдя на более крупный тарифный план.
- Получите сервер с выделенным безлимитным восходящим каналом 100/1000/10000 Мбит, что позволит вам перейти от стандартного решения для хостинга к чему-то более адаптированному для вашего варианта использования.
- Переведите ваши требования к широковещательной передаче в сеть доставки контента (CDN). Это означает, что вы, вероятно, можете остаться на текущем плане хостинга, потому что большая часть трафика будет обслуживаться CDN, и у вас также нет никаких изменений в вашем рабочем процессе.
Первый часто не очень рентабелен, многие Общие планы хостинга хорошо работают только со многими небольшими сайтами с относительно низким трафиком, а крупные сайты не подходят для этой бизнес-модели, поэтому часто цены рассчитаны так, чтобы вас отпугнуть, когда вы достигнете определенного предела.
Второй не обязательно является самый дешевый, но дает вам большую гибкость, если вы можете позволить себе потратить время на приобретение необходимых навыков и тестирование предлагаемых (программных) конфигураций. Обычно самые быстрые данные поступают из памяти, тогда как SSD, SAS и SATA диски отстают, но также являются самым дешевым хранилищем. Что-то, что кэширует самые популярные / текущие файлы в памяти, должно быть самым быстрым (например, Varnish), хотя Linux обычно в любом случае использует любую неиспользуемую память в качестве дискового кеша, и любой легкий веб-сервер должен быть достаточным для статического содержимого.
Даже если вы не используете бесплатный CDN, такой как cloudflare, CDN может оказаться намного дешевле, чем варианты 1 и 2.
Что-то, что кэширует самые популярные / текущие файлы в памяти, должно быть самым быстрым (например, Varnish), хотя Linux обычно в любом случае использует любую неиспользуемую память в качестве дискового кеша, и любой легкий веб-сервер должен быть достаточным для статического содержимого.Даже если вы не используете бесплатный CDN, такой как cloudflare, CDN может оказаться намного дешевле, чем варианты 1 и 2.
Что-то, что кэширует самые популярные / текущие файлы в памяти, должно быть самым быстрым (например, Varnish), хотя Linux обычно в любом случае использует любую неиспользуемую память в качестве дискового кеша, и любой легкий веб-сервер должен быть достаточным для статического содержимого.Даже если вы не используете бесплатный CDN, такой как cloudflare, CDN может оказаться намного дешевле, чем варианты 1 и 2.