Almacenamiento en caché del lado del servidor en openrasta

Question

Tengo un sitio que se está sondeando bastante difícil para la representación JSON de los mismos recursos de varios clientes (navegadores, otras aplicaciones, scripts de shell de Unix, scripts de Python, etc.).

Me gustaría agregar un poco de almacenamiento en caché de modo que algunos de los recursos se guarden en caché dentro del servidor durante un tiempo configurable, para evitar que la CPU acceda a la solicitud y serialice el recurso a JSON. Por supuesto, podría almacenarlas en caché en los manejadores, pero luego tomaría el hit de serialización en cada solicitud, y también tendría que modificar montones de manejadores.

He mirado en el módulo openrasta de almacenamiento en caché, pero creo que esto es sólo para el control de la caché del navegador? Así
alguna sugerencia sobre cómo puedo conseguir openrasta para almacenar en caché la representación prestado del recurso, después de que el códec que ha generado?

Gracias

Answer 1

openrasta de almacenamiento en caché tiene soporte preliminar para el almacenamiento en caché del lado del servidor, con una API puede asignar a la caché del lado del servidor asp.net, utilizando el atributo ServerCaching. Dicho esto, no está completo, tampoco es openrasta-caché para el caso. Es un 0.2 que necesitaría un par de días de trabajo para llegar a una buena v1 que admita por completo todos los escenarios que quería admitir y que la infraestructura de almacenamiento en caché de asp.net no admite actualmente (principalmente, hacer que el almacenamiento en caché en OpenRasta funcione exactamente como un intermediario http en lugar de un objeto y .net céntrico como existe en asp.net land, incluido el control del cliente de la memoria caché del servidor para los momentos en los que desea que se le permita al cliente forzar al servidor a rehacer la consulta). Como actualmente no tengo ningún proyecto de cliente que trabaje en el almacenamiento en caché, es difícil justificar cualquier trabajo adicional sobre ese complemento, por lo que no estoy codificando nada en este momento. Sin embargo, tengo 4 días libres por venir, así que si tengo DM, desearía que el openrasta-caching fuera transferido a 0.3 con los requisitos que usted tenga en eso, que se ajusten a 4 días de trabajo.

Puede implementar algo más simple usando un IOperationInterceptor y conectando la tubería asp.net usando eso, o sea más amigable para la web e implemente su caché fuera del proceso usando squid y confíe en openrasta-caching para generar el almacenamiento en caché http correcto instrucciones.

Dicho esto, para su problema, es posible que ni siquiera necesita el almacenamiento en caché del servidor si el costo es en JSON. Si asigna un último modificado o un eTag a lo que el regreso del guía, que va a generar correctamente un 304 en su caso, la representación de derivación y JSON alltogether, siempre que su cliente hace peticiones condicionales (y debería).

También hay una API propuesta para permitirle optimizar aún más su API haciendo una primera consulta sobre la última modificación/etag para devolver el 304 sin recuperar ningún dato.