Подтвердить что ты не робот

Какой метод кеширования является самым быстрым/легким для Node/Mongo/NginX?

Мне поручено работать над проектом для клиента, у которого есть сайт, который он оценивает, будет получать 1-2 миллиона обращений в день. У него есть существующая база данных пользователей 58M, которые необходимо засеять на основе регистрации для нового бренда. Большая часть контента сайта обслуживается внешними данными, предоставленными API, причем большинство данных, хранящихся в нашей настройке Mongo, являются информацией профиля и сохраненными параметрами API.

NginX будет находиться на порту 80 и балансировке нагрузки в кластере Node на портах 8000 - 8010.

Мой вопрос - что делать с кешированием. Я исхожу из фона LAMP, поэтому я привык либо писать статические HTML файлы с PHP, либо обслуживать их, чтобы минимизировать нагрузку MySQL или использовать Memcached для сайтов, требующих более высокого уровня кэширования. Эта настройка немного чуждо мне.

Какой из них наиболее идеален для минимального времени отклика и загрузки процессора?

1: кеширование уровня страницы с помощью NginX

Ссылка: http://andytson.com/blog/2010/04/page-level-caching-with-nginx/

server {
    listen            80;
    servername        mysite.com;

    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  Host       $host;

    location / {
        proxy_pass    http://localhost:8080/;
        proxy_cache   anonymous;
    }

    # don't cache admin folder, send all requests through the proxy
    location /admin {
        proxy_pass    http://localhost:8080/;
    }

    # handle static files directly. Set their expiry time to max, so they'll
    # always use the browser cache after first request
    location ~* (css|js|png|jpe?g|gif|ico)$ {
        root          /var/www/${host}/http;
        expires       max;
    }
}


2: Redis как ведро кэша

Функция hash() является функцией numbers() на этой странице: http://jsperf.com/hashing-strings

function hash(str) {
    var res = 0,
        len = str.length;
    for (var i = 0; i < len; i++) {
        res = res * 31 + str.charCodeAt(i);
    }
    return res;
}

var apiUrl = 'https://www.myexternalapi.com/rest/someparam/someotherparam/?auth=3dfssd6s98d7f09s8df98sdef';
var key    = hash(apiUrl).toString(); // 1.8006908172911553e+136

myRedisClient.set(key,theJSONresponse, function(err) {...});


3: Node записать файлы JSON

Функция hash() является функцией numbers() на этой странице: http://jsperf.com/hashing-strings

function hash(str) {
    var res = 0,
        len = str.length;
    for (var i = 0; i < len; i++) {
        res = res * 31 + str.charCodeAt(i);
    }
    return res;
}

var fs     = require('fs');
var apiUrl = 'https://www.myexternalapi.com/rest/someparam/someotherparam/?auth=3dfssd6s98d7f09s8df98sdef';
var key    = hash(apiUrl).toString(); // 1.8006908172911553e+136

fs.writeFile('/var/www/_cache/' + key + '.json', theJSONresponse, function(err) {...});


4: Лак впереди

Я сделал некоторые исследования и тесты, такие как показанные на этом сайте, отталкивают меня от этого решения, но я все еще готов рассмотреть его, если это имеет наибольший смысл: <а3 >

4b9b3361

Ответ 1

Я бы сделал комбинацию и использовал Redis для кэширования вызовов API пользовательского интерфейса сеанса, которые имеют короткий TTL, и используют Nginx для кэширования долгосрочных RESTless-данных и статических активов. Я бы не писал JSON файлы, так как я предполагаю, что файловая система IO будет самой медленной и наиболее интенсивной в CPU из перечисленных опций.

Ответ 2

  • nginx кэширование на уровне страницы подходит для кэширования статического контента. Но для динамического контента это нехорошо. Например, как вы делаете недействительным кеш, если содержимое изменяется в восходящем потоке?

  • Redis идеально подходит для хранения данных в памяти. Но я не люблю использовать его в качестве кеша. При ограниченном объеме памяти мне приходится постоянно беспокоиться о нехватке памяти. Да, вы можете настроить стратегию для истечения ключей в redis. Но эта дополнительная работа и все еще не так хороша, как я хочу, чтобы она была поставщиком кешей.

Не имейте опыта выбора 3 и 4.

Я удивлен, что здесь вы не включаете memcache. По моему опыту, он прочный в качестве поставщика кеша. Одна функция memcache, которую redis не имеет, заключается в том, что она не гарантирует, что срок действия ключа не будет истечен указанным вами временем истечения срока действия. Это плохо для хранилища данных, но делает memcache идеальным кандидатом для кэширования: вам не нужно беспокоиться об использовании памяти, которую вы назначили memcache. memcache удалит менее используемые ключи (менее используемый кеш), хотя время истечения этих ключей еще не выполнено.

Nginx предоставляет этот модуль memcache. Он прочный. Несколько учебных пособий, если вы в Интернете онлайн.

Мне нравится больше всего (см. ссылку ниже). Недопустимость кэширования проста: например, если страница обновляется вверху, просто удалите ключ memcache с сервера приложений вверх. Автор заявлял о 4-кратном увеличении времени отклика. Поверьте, это достаточно хорошо для вашего случая использования.

http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/

Ответ 3

Что касается лака, я не собираюсь расшифровывать тесты на найденном вами сайте, но могу сказать, что они ужасно плохие номера и не имеют ничего общего с реализацией реального трафика (google для оптимизации лаков и просмотра тестов, показывающих 100-200k req/s вместо 8k).

Nginx также является выбором OK для кеша страниц и с 1-2 Мбит в день, когда вам не нужна экстремальная производительность. Так что идите с тем, с кем вам удобнее работать.

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

Кроме того, redis/memcached лучше всего поможет вам масштабировать приложение, если вы используете его как кеш объекта или кеш для обычно используемых десериализованных данных.