Какой у вас опыт использования nginx и memcached для оптимизации веб-сайта?

Question

У нас есть веб-приложение на основе Java EE, работающее на кластере серверов приложений Glassfish . Входящий трафик будет в основном представлять собой запросы RESTful для представлений ресурсов нашего приложения на основе XML, но, возможно, 5% трафика может быть для представлений на основе JSON или XHTML / CSS.

Сейчас мы исследуем решения для балансировки нагрузки для распределения входящего трафика между экземплярами Glassfish в кластере. Мы также изучаем, как разгрузить кластер, используя memcached, распределенную хеш-карту в памяти, ключами которой будут имена ресурсов REST (например, "/ user / bob", "/ group / jazzlovers") и чьи значения соответствующие представления XML.

Один из подходов, который звучит многообещающе, - убить обеих птиц одним камнем и использовать легкий, быстрый nginx HTTP-сервер / обратный прокси. Nginx будет обрабатывать каждый входящий запрос, сначала просматривая его URI в memcached, чтобы увидеть, есть ли там еще не истекшее представление XML. Если нет, nginx отправляет запрос одному из экземпляров Glassfish. Memcached модуль nginx описан в этой короткой записи .

Какое у вас общее впечатление от использования nginx и memcached, насколько вы счастливы с ними? Какие ресурсы вы нашли наиболее полезными для изучения о них? Если вы попробовали их, и они не соответствовали вашим целям, почему бы и нет, и что вы использовали вместо этого?

Примечание: вот связанный вопрос .

Обновление: позже я задал тот же вопрос на ServerFault.com. Ответы там в основном предлагают альтернативы nginx (полезно, но косвенно).

Answer 1

Предполагается, что у вас есть банк серверов приложений для передачи данных пользователям.

upstream webservices {
    server 10.0.0.1:80;
    server 10.0.0.2:80;
    server 10.0.0.3:80;
}
server {
    ... default nginx stuff ...
    location /dynamic_content {
          memcached_pass localhost:11211;
          default_type   text/html;
          error_page     404 502 = @dynamic_content_cache_miss;
          set $memcached_key $uri;
    }
    location @dynamic_content_cache_miss {
          proxy_pass http://webservices;
    }

То, что делает приведенный выше фрагмент nginx.conf, направляет весь трафик с http://example.com/dynamic/* НАПРЯМУЮ на сервер memcached. Если в memcache есть контент, ваши вышестоящие серверы не увидят ЛЮБОГО трафика.

Если попадание в кэш завершается неудачно с ошибкой 404 или 502 (нет в кеше или невозможно достичь memcache), тогда nginx передаст запрос вышестоящим серверам. Поскольку в вышестоящем определении есть три сервера, вы также получаете прозрачный прокси балансировки нагрузки.

Теперь единственное предостережение заключается в том, что вы должны убедиться, что ваши серверы внутренних приложений сохраняют данные в memcache свежими. Я использую nginx + memcached + web.py для создания простых маленьких систем, которые обрабатывают тысячи запросов в минуту на относительно скромном оборудовании.

Общий псевдокод для сервера приложений такой же, как для web.py

class some_page:
     def GET(self):
         output = 'Do normal page generation stuff'
         web_url = web.url().encode('ASCII')
         cache.set(web_url, str(output), seconds_to_cache_content)
         return output

Важные вещи, которые следует помнить в приведенном выше псевдокоде web.py /, - это то, что содержимое, поступающее из memcached через nginx, вообще не может быть изменено. nginx использует простые строки, а не юникод. Если вы сохраните вывод Unicode в memcached, вы получите по крайней мере странные символы в начале и в конце вашего кэшированного содержимого.

Я использую nginx и memcached для спортивного веб-сайта, где мы получаем огромные импульсы трафика, которые длятся всего несколько часов. Я не мог обойтись без nginx и memcached. Нагрузка на сервер во время нашего последнего большого спортивного события четвертого июля упала с 70% до 0,6% после внесения вышеуказанных изменений. Я не могу рекомендовать это достаточно.