Hay una gran cantidad de principios que se aplican a cualquier sitio web, irrelevantes de la pila subyacente:
- instalaciones de almacenamiento en caché el uso de HTTP. Para uno, está el caché de agente de usuario. En segundo lugar, toda la red troncal está llena de proxies que pueden almacenar en caché sus solicitudes, así que aproveche esto al máximo. Una solicitud que incluso llega a su servidor agregará 0 a su carga, no puede optimizar mejor que eso :)
- corolario al punto anterior, use CDN (Content Delivery Network, como CloudFront) para su contenido estático. CSS, JPG, JS, HTML estático y muchas más páginas pueden ser servidas desde un CDN, ahorrando así al servidor web de una solicitud HTTP.
- segundo corolario del primer punto: agregue las sugerencias de caché de expiración a su contenido dinámico. Incluso una vida útil de caché corta, como 10 segundos, ahorrará muchos hits que, en su lugar, recibirán todos los servidores proxy que se encuentran entre el cliente y el servidor.
- Minimice el número de solicitudes HTTP. Parece básico, pero es probablemente la mejor optimización que se pasa por alto. De hecho, las mejores prácticas de Yahoo lo ubican como la mejor optimización, consulte Best Practices for Speeding Up Your Web Site.Aquí está la lista de las prácticas de sus apuestas:
- Minimizar las solicitudes HTTP
- utilizar una red de distribución de contenidos
- Añadir un Expira o un encabezado Cache-Control
- Componentes Gzip
- ... (la lista es bastante largo en realidad, acabo de leer en el enlace anterior)
Ahora, después de eliminado tanto como sea posi de los éxitos superfluos, aún te queda la posibilidad de optimizar las solicitudes que lleguen a tu servidor. Una vez que el código ASP comienza a correr, todo va a palidecer en comparación con las peticiones de base de datos:
- Reducir el número de llamadas de DB por página. La mejor optimización posible es, obviamente, no hacer la solicitud al DB para comenzar. Algunos dicen que 4 lecturas y 1 escritura por página son lo máximo que debe soportar un servidor de carga alta, otro decir una llamada de DB por página, y aún así digamos que 10 llamadas por página están bien. El punto es que menos es siempre mejor que más, y las escrituras son significativamente más costosas que las lecturas. Revisar su diseño de interfaz de usuario, tal vez eso recuento de visitas en la esquina de la página que nadie ve no tiene por qué ser que precisa ...
- Asegúrese de que cada petición DB envía al servidor SQL está optimizado . Mire todos y cada uno de los planes de consulta, asegúrese de tener el covering indexes en su lugar, asegúrese de no hacer ninguna exploración de tabla, revisar su estrategia clustered index design, revisar toda su carga de I/O, diseño de almacenamiento, etc. etc. Realmente, no hay atajo puede tomarla, usted tiene que analizar y optimizar el diablo de su base de datos, será sea su punto de chocking.
- eliminan la contención. No haga que los lectores esperen a los escritores. Para tu stack, SNAPSHOT ISOLATION es obligatorio.
- caché resultados. Y generalmente esto es donde la galleta se desmorona. Diseñar un buen caché en realidad es bastante difícil de lograr. Le recomendaría que vea la nota clave de Facebook SOCC: Building Facebook: Performance at Massive Scale. En algún lugar de la diapositiva 47 muestran cómo es una API interna típica de Facebook:
.
cache_get (
$ids,
'cache_function',
$cache_params,
'db_function',
$db_params);
Todo se solicita desde una memoria caché, y si no lo encuentra, pidió desde su extremo posterior de MySQL. Probablemente no comience con 60000 servers pensado :)
En la pila de SQL Server, la mejor estrategia de almacenamiento en caché es una basada en Query Notifications. Puede casi mezclarlo con LINQ ...
1 Interesante. –