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

Question

Estoy en el proceso de desarrollar un sitio de red social.

Y he estado pensando en la escalabilidad desde el primer día del proyecto, he ajustado el sitio y las consultas de la mejor manera posible.

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

Pero no estoy muy seguro de lo que debería almacenar en caché y no caché. O si los tiempos de carga de la página actual de 1 segundo son buenos o malos. La consulta más pesada es información de los miembros que esta consulta obtiene toda la información del miembro y todo lo relacionado con ellos como en este caso sus objetivos, entradas de tipo de blog, estímulos, fotos, actualizaciones de estado (como Twitter), información del blog (para cruzar sus entradas) etc. etc.

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

Answer 1

Implementaré el almacenamiento en caché en todas y cada una de las capas de su aplicación si es posible.

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

En términos de LO que necesita para almacenar en caché, los objetos a los que se accederá repetidamente deben almacenarse en caché, especialmente aquellos que es poco probable que cambien con mucha frecuencia. A continuación, puede restablecer la memoria caché de ese objeto solo cuando se edita. (Tenga cuidado con el almacenamiento en caché de objetos que se actualizan con frecuencia, ya que un ciclo constante de sustitución de la memoria caché en casi todas las cargas degradará el rendimiento en lugar de mejorarlo)

Para medir el rendimiento, no me fijaría en cuánto tarda una página para cargar, pero busca algunas herramientas de medición de rendimiento, ya que realmente necesitas probar qué tan rápido cada página funciona bajo presión. La página de información del usuario puede no ser el objetivo de almacenamiento en caché más grande si, por ejemplo, rara vez se accede a ella. Debería centrarse en las páginas más utilizadas.

Answer 2

La carga de la página pregunta ya se le preguntó:

Lo que se considera un buen tiempo de respuesta para una aplicación web dinámica, personalizada?

En términos de almacenamiento en caché, debe medir la cantidad de tiempo que se usaría para cargar los datos cada vez frente a la carga desde el caché. Cuanto más grande es el caché, menos efectivo se vuelve. Por lo tanto, no desea cargar demasiados datos en la memoria caché. Lo que usamos aquí es un caché continuo, con los datos utilizados menos recientemente que se descartan una vez que alcanzamos el límite de tamaño de caché. A continuación, ajuste el límite de acuerdo con los resultados de rendimiento reales.

Answer 3

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

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

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

Answer 4

La respuesta típica es:

• información de caché que rara vez se actualiza.
• No almacenar en caché lo que cambia con frecuencia.

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

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

• JS Tiempo de carga: 0.274
• de consultas Incluido: 15
• PHP Tiempo de carga: 0,0524
• Uso de memoria: 1.013 MB

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

Answer 5

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

Por lo que respecta al almacenamiento en caché u otra optimización del rendimiento, le recomiendo 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 agregar lógica de almacenamiento en caché a algo que ya funciona bien. Por otro lado, pueden producirse problemas de rendimiento en los que podría no esperarlos, con datos que quizás no haya considerado almacenar en caché.

Algo que también he encontrado con las pruebas de rendimiento es que puede encontrar lugares en su código donde se producen bloqueos, o donde las simples optimizaciones de bases de datos podrían ayudar. Quizás agregar un índice a una tabla acelere una página en lugar de agregar un montón de lógica de almacenamiento en caché.

Lo mantendría simple, y lo refactorizaré para el rendimiento solo donde lo necesite.

Además, pruebe temprano y realice pruebas con frecuencia. Sé que mucha gente dice que consideran que el rendimiento es el último, pero realmente puede codificarse en una esquina si al menos no comienza a considerarlo al principio del ciclo de vida de desarrollo.

Answer 6

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