node.js - nodejs - node js express cache

¿Qué método de almacenamiento en caché es el más rápido/ligero para Node/Mongo/NginX?

Question

Se me ha asignado la tarea de trabajar en un proyecto para un cliente que tiene un sitio que él estima que recibirá de 1 a 2 millones de visitas por día. Él tiene una base de datos existente de 58 millones de usuarios que necesitan ser sembrados por registro para la nueva marca. La mayor parte del contenido del sitio se proporciona a partir de datos suministrados por la API externa, y la mayoría de los datos almacenados en nuestra configuración de Mongo son información de perfil y parámetros de API guardados.

NginX estará en el puerto 80 y el equilibrio de carga en un clúster de Nodo en los puertos 8000 - 8010.

Mi pregunta es qué hacer con el almacenamiento en caché. Vengo de un fondo LAMP, por lo que estoy acostumbrado a escribir archivos HTML estáticos con PHP y a servirlos para minimizar la carga de MySQL o usar Memcached para sitios que requieren un mayor nivel de almacenamiento en caché. Esta configuración es un poco extraña para mí.

¿Cuál es el más ideal en cuanto a tiempo de respuesta mínimo y carga de CPU ?

1: almacenamiento en caché a nivel de página con NginX

Referencia: 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 como un cubo de caché

La hash() es la función numbers() en esta página: 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: Nodo escribe archivos JSON

La hash() es la función numbers() en esta página: 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: Barniz en frente

Hice algunas investigaciones y los puntos de referencia como los que se muestran en este sitio me están alejando de esta solución, pero todavía estoy abierto a considerarlo si tiene más sentido: http://todsul.com/nginx-varnish

Answer 1

1. El almacenamiento en caché a nivel de página nginx es bueno para almacenar en caché contenido estático. Pero para el contenido dinámico, no es bueno. Por ejemplo, ¿cómo se invalida el caché si el contenido se modifica en sentido ascendente?

2. Redis es perfecto para el almacén de datos en memoria. Pero no me gusta usarlo como caché. Con una cantidad limitada de memoria, tengo que preocuparme constantemente por quedarme sin memoria. Sí, puede configurar la estrategia para vencer claves en redis. Pero eso es un trabajo adicional y todavía no es tan bueno como quiero que sea un proveedor de caché.

No tiene experiencia en las opciones 3 y 4.

Me sorprende que no incluyas memcache aquí como una opción. Desde mi experiencia, es sólido como un proveedor de caché. Una característica de memcache que redis no tiene es que no garantiza que una clave no caduque antes del tiempo de caducidad especificado. Esto es malo para un almacén de datos, pero convierte a memcache en un candidato perfecto para el almacenamiento en caché: no necesita preocuparse por el uso de la memoria asignada a memcache. memcache eliminará las claves menos utilizadas (la memoria caché menos utilizada) aunque el tiempo de caducidad de esas claves aún no se haya cumplido.

Nginx proporciona este módulo de memcache incorporado . Es solido Una serie de tutoriales si google en línea.

Este es el que más me gusta (ver enlace abajo). La invalidación de caché es fácil: por ejemplo, si una página se actualiza en sentido ascendente, simplemente elimine la clave memcache del servidor de aplicaciones ascendente. El autor afirmó 4 veces el aumento del tiempo de respuesta. Creo que es lo suficientemente bueno para su caso de uso.

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

Answer 2

En cuanto al barniz, no tengo la intención de descifrar los puntos de referencia en el sitio que encontraste, pero puedo decirte que son números muy malos y no tiene nada en común con una implementación real de alto tráfico (busque las optimizaciones de barnices en Google y vea los puntos de referencia que muestran 100-200k req / s en lugar de 8k).

Nginx también es una buena opción para un caché de página y con 1-2M hits al día no necesita un rendimiento extremo. Así que ve con el que te sientas más cómodo trabajando.

Las dos soluciones de nodo son realmente una opción peor. Un caché de página debe estar separado de su aplicación dinámica para proporcionar confiabilidad y rendimiento.

Además, redis / memcached lo ayudará mejor a escalar la aplicación si la usa como un caché de objetos o un caché para los datos deserializados que se usan comúnmente.

Answer 3

Haría una combinación y utilizaría Redis para almacenar en la memoria caché las llamadas a la API del usuario que tienen un TTL corto, y utilizar Nginx para almacenar en caché datos RESTless a largo plazo y activos estáticos. No escribiría archivos JSON como imagino que el sistema de archivos IO sería el más lento y el más intensivo de CPU de las opciones enumeradas.