¿Cuál es la información correcta para almacenar en caché? ¿Qué es un buen tiempo de carga de la página?

Question

Estoy en el proceso de desarrollar un sitio de redes sociales.

Y pensando en la escalabilidad desde el primer día del proyecto, he mejorado el sitio y las consultas lo mejor que he podido.

Sin embargo; Ciertas páginas son muy pesadas y no estoy seguro de si se están cargando lo más rápido posible, así que estaba pensando en implementar una solución de almacenamiento en caché distribuida.

Pero no estoy seguro de lo que debo almacenar en caché y no en caché. O si los tiempos de carga de la página actual de 1 segundo son buenos o malos.

La consulta más importante es obtener información de los miembros; esta consulta obtiene toda la información de los miembros y cualquier cosa relacionada con ellos, como en el caso de este sitio, sus objetivos, entradas de tipo de blog, animaciones, fotos, actualizaciones de estado (como Twitter), información del blog (para crossposting sus entradas) etc. etc.

De todos modos, ¿debo guardar en caché esta información? ¿Y crees que los tiempos de carga de 1 segunda página son razonablemente rápidos? Algunas páginas tienen menos de un segundo entre 4-6 décimas de segundo.

Answer 1

Si fuera posible, implementaría el almacenamiento en caché en cada capa de tu aplicación.

Puede almacenar en caché páginas al nivel más alto, objetos a nivel de código y asegurarse de que su base de datos almacene en caché las consultas y los datos clave correctamente en el nivel más bajo.

En lo que se refiere a QUÉ es necesario que se almacene en la memoria caché, se debe almacenar en caché cualquier objeto al que se accederá de manera reiterada, especialmente aquellos que es poco probable que cambien con mucha frecuencia. A continuación, puede restablecer el caché de ese objeto solo cuando se edita. (Tenga cuidado con el almacenamiento en caché de los objetos que se actualizan con frecuencia como un ciclo constante de reemplazo de la caché en casi todas las cargas, lo que degradará el rendimiento en lugar de mejorarlo)

Para medir el rendimiento, no miraría cuánto tarda en cargarse una sola página, pero busque en Google algunas herramientas de medición de rendimiento, ya que realmente necesita probar qué tan rápido se desempeña cada página bajo presión. Es posible que su página de información de usuario no sea el mayor destino de almacenamiento en caché si, por ejemplo, rara vez se accede a ella. Debes centrarte en las páginas más utilizadas.

Answer 2

La respuesta típica es:

• Información de caché que rara vez se actualiza.
• No almacene en caché los cambios que se producen con frecuencia.

En su caso, podría almacenar en caché todo en archivos planos (por ejemplo, un archivo por usuario) y destruir un archivo de caché de usuario cada vez que el correspondiente actualice algo. Si el archivo de caché no existe, créelo antes de mostrar el contenido asociado.

Ahora sobre el tiempo de carga (que puede ser muy diferente según la ubicación del usuario), aquí hay algunos números informativos de un foro de PHP de un sitio de juegos:

• Tiempo de carga JS: 0.274
• Recuento de consultas: 15
• Tiempo de carga de PHP: 0.0524
• Uso de memoria: 1.013 MB

Y esto es considerado por la comunidad como una buena experiencia. Pero es terriblemente subjetivo.

Answer 3

La pregunta de carga de la página ya se hizo:

¿Qué se considera un buen tiempo de respuesta para una aplicación web dinámica y personalizada?

En términos de almacenamiento en caché, debe medir la cantidad de tiempo que pasaría cargando los datos cada vez en lugar de cargarlos desde el caché. Cuanto más grande es el caché, menos efectivo se vuelve. Por lo tanto, no desea cargar demasiados datos en el caché. Lo que usamos aquí es un caché rodante, con los datos menos utilizados recientemente que se eliminan una vez que alcanzamos el límite de tamaño de caché. Luego, ajuste el límite de acuerdo con los resultados de rendimiento reales.

Answer 4

Para los datos específicos del perfil de usuario, almacene todo lo que pueda en un ticket / cookie de FormsAuth. Cachear (HttpContext.Current.Cache) los elementos específicos del usuario requerirán X recursos en su servidor por usuario, lo mismo que lo haría la sesión (pero con menos dolor de cabeza). Si puede descargar tanto como sea posible en el Boleto o cookie de los usuarios (es como 4K), realmente ayudará al rendimiento de sus servidores al escalar.

Solo debe recuperar los bits de información que necesita la página. Por ejemplo, si está cargando datos de un blog, NO cargue fotos. Es más trabajo, sí, pero si desea escalar, tendrá que analizar las necesidades de cada página.

Asegúrese de comprender que existen diferencias entre el almacenamiento en caché de consultas de base de datos (reutilización del plan de ejecución), el almacenamiento en caché de objetos (Httpcontext.Cache) y el almacenamiento en caché de páginas (Response.Headers [Expires]).

Answer 5

El gurú del diseño web Vincent Flanders sugiere que algo más de 4 segundos es demasiado largo para que se cargue una página web . Creo que esta es una buena regla general.

En cuanto al almacenamiento en caché u otra optimización de rendimiento, le recomendaría que realice algunas pruebas de rendimiento. Hay una serie de kits de pruebas de rendimiento disponibles en el mercado. Las pruebas mostrarán dónde están las áreas problemáticas. No tiene sentido que agregue la lógica de almacenamiento en caché a algo que ya funciona bien. Por otro lado, pueden surgir problemas de rendimiento en los que puede no esperarlos, lo que implica datos que tal vez no haya considerado el almacenamiento en caché.

Algo que también he encontrado con las pruebas de rendimiento es que puede encontrar puntos en su código en los que se producen puntos muertos o en las que una simple optimización de la base de datos ayudaría. Quizás agregar un índice a una tabla acelerará una página en lugar de agregar un montón de lógica de almacenamiento en caché.

Lo mantendría simple y refactorizaría el rendimiento solo cuando sea necesario.

También, prueba temprano y prueba a menudo. Sé que mucha gente dice que hay que considerar que el desempeño es el último, pero realmente puedes encerrarte en una esquina si al menos no comienzas a considerarlo al principio del ciclo de vida del desarrollo.

Answer 6

Algunas investigaciones sugieren que la aplicación interactiva debe proporcionar comentarios dentro de 250 ms para que el usuario no piense que está atascado o que la operación haya fallado. Sin embargo, el nivel de aceptación en la web es un poco más alto, y el navegador web suele proporcionar comentarios de que se está cargando una nueva página. Con AJAX, debes tener cuidado de proporcionar algún tipo de comentarios, ya que el navegador no mostrará lo que está sucediendo.