Два маленьких httpd сервера или один большой?

Question

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

Прямо сейчас я использую Rails 3.1 с NGINX и Passenger.

Пока что я настроил систему так, чтобы ВСЕ активы обслуживались через домен, аналогичный тому, который есть у меня сейчас (это не поддомен, а другой домен... таким образом, любые файлы cookie из реального домена не будут быть переданы в рамках запросов). Сервер NGINX имеет следующие конфигурации:

server {
listen 80;
server_name similarwebsite.com;
root /path/to/static/files;
}

server {
listen 80;
server_name website.com;
root /path/to/rails/files/public;
}

Я считаю, что гораздо лучше иметь отдельную среду для ресурсов, чем в Rails (мне действительно не нравятся все абстракции Rack, которые используются только для предоставления нескольких простых ресурсов).

Теперь мой вопрос остается, должен ли я разделить статические файлы на другой HTTP-сервер, такой как thttpd? На данный момент они оба работают на одной машине, но все ресурсы будут передаваться через thttpd, а все ресурсы с помощью nginx. Экземпляр thttpd может работать на другом IP-адресе или порте. Просто интересно, если это сделает это быстрее.

Есть идеи? Я иду слишком далеко?

Answer 1

Оказывается, я просто использовал один ht tp-сервер NGINX для обслуживания как динамических, так и статических файлов. Статические файлы находились в другом домене, и это решение было лучшим с наименьшим объемом работы по настройке.

Answer 2

Хорошая идея отделить статический контент. Возможно, вам следует пойти еще дальше и использовать CDN (сеть доставки контента). Я использовал Akamai и Amazon Cloud Front, у каждого из которых есть расходы, связанные с их производительностью. Есть и недорогие (бесплатные!?) Альтернативы. Смотрите вики-страницу для CDN для получения дополнительной информации: http://en.wikipedia.org/wiki/Content_delivery_network

Answer 3

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