Recopilación de artículos sobre ahorro de ancho de banda

Autor: Armonth | El viernes 13 de abril del 2007 @ 06:29.

Hoy parece ser el día de los "sucesos relacionados al ancho de banda", primero he leído un artículo de Max Glaser en que habla sobre el ahorro en ancho de banda y trata una parte que yo anteriormente no he mencionado: identificar las mayores fuentes de consumo.

En resumen habla de usar alguna herramienta para identificar donde se va el consumo (HTML, imágenes, ficheros, etcétera) para actual en consecuencia y luego usar compresión gzip/zlib. El artículo también incluye una imagen con una gráfica del ahorro que eso supone.

Otra ventaja de comprimir las páginas webs bajo demanda es que lo que aumenta de consumo de CPU por un lado puede reducirse relativamente (según que casos) por el otro. Si tenemos muchas visitas el mantener tantos hilos del Apache abiertos enviando puede suponer más gasto de CPU y al enviarlas más rápidamente los picos pueden ser menos escarpados.

Otra solución en ese punto es tener dos versiones de la página a enviar, una sin comprimir y otra comprimida. Luego se envía la que más le interese al navegador ("negociación de contenidos"). Eso precisamente es lo que me comento Ricardo Galli en una charla de WP-Cache cuando le pregunte si había alguna manera de usar cache + gzip, aunque aún estoy esperando ver si se pone a ello xD

También hoy, he conocido otro caso de hotlinking peligroso (en dicho enlace comento como deshabilitar el hotlinking completamente), algo aparentemente sin importancia: un blog tiene en su servidor una imagen, la cual usan como avatar en un foro muy conocido y pum: 50.000 visitas de golpe en menos de 24 horas y para no aplicar la medida a todos ni usar listas blancas hemos hecho una ligera modificación:

RewriteEngine On   
RewriteCond %{HTTP_REFERER} foro-a-filtrar.com   
RewriteRule .(jpe?g|gif|bmp|png)$ hotlinking.gif [L]

Con todo ello, ahí va un pequeño listado de artículos publicados en SigT sobre ahorro de ancho de banda (alguno incluso tiene más de un año y tiene total vigencia):

La realidad es que existen tantas cosas que se pueden tocar, optimizar y afinar empezando por el script (su programación...), el uso que hacen del mismo (quien y cómo accede...), para bajar al software servidor (apache, php, mysql...) y aún más al sistema operativo (y sobretodo cómo de optimizado están cosas como el kernel o si has compilado todo lo anterior para dejarlo a tus necesidades) que a menudo se hace difícil de creer que llegue el momento de decir "ya no haya nada más que raspar" de un servidor y haya que mudarse a otro.

Comentarios