Reducir uso de CPU y memoria del servidor
¡OJO! Probablemente este artículo sólo te interese si tienes un servidor donde alojas algún blog o sitio web.
Antes de comenzar, debemos tener claros una serie de conceptos que vamos a manejar bastante en este manual. Si ya los conoces, puedes saltártelos:
- Referer o referido: Es la página de donde procede el visitante. Te reporta sitios desde donde se accede a tu página (buscadores -con las palabras clave que buscó-, foros -donde te citaron-, blogs -que te han mencionado-, etc...).
- Requests o peticiones. Se llama así a cada uno de los accesos a ficheros de tu página (imagenes, páginas, descargas, etc...). Es importante darse cuenta de que una petición a una página conlleva varias peticiones asociadas a todas las imagenes y otros recursos que la componen (siempre que estén dentro de tu servidor).
Sistema anti-hotlink
La primera solución en estos casos es recurrir a un sistema anti-hotlink: Evitar que usen las imágenes de nuestro servidor en otras páginas. En la mayoría de los sitios proponen un código donde bloquear todas las páginas excepto una lista blanca que crearemos. Sin embargo, esta solución no me agrada demasiado.
Armonth se acerca más a lo que considero mi sistema anti-hotlink ideal: un código donde no bloquear ninguna página salvo las de una lista negra.
# Sistema anti hotlink
RewriteCond %{HTTP_REFERER} \.wordpress\.com [OR]
RewriteCond %{HTTP_REFERER} \.myspace\.com [OR]
RewriteCond %{HTTP_REFERER} \.spaces\.live\.com [OR]
RewriteCond %{HTTP_REFERER} \.blogcindario\.com [OR]
RewriteCond %{HTTP_REFERER} \.blogspot\.com [OR]
RewriteCond %{HTTP_REFERER} youtube\.com [OR]
RewriteCond %{HTTP_REFERER} blogger\.com [OR]
RewriteCond %{HTTP_REFERER} livejournal\.com [OR]
RewriteCond %{HTTP_REFERER} miarroba\.com [OR]
RewriteCond %{HTTP_REFERER} showthread\. [OR,NC]
RewriteCond %{HTTP_REFERER} viewtopic\. [NC]
RewriteRule \.(jpg|gif|png)$ /img/hotlink.png [L]
El único defecto es el no proteger del enlazado en foros, así que le añadí showthread y viewtopic, nombre de variables bastante comunes en foros.
Es importante también que no tengamos ningún foro en nuestra página. Si lo tenemos, tendríamos que incluirlo en una lista blanca, para no bloquear imágenes en nuestro sitio.
Bots/Agentes masivos
Muchas veces existen bots o usuarios que realizan demasiadas peticiones, a veces inconscientemente, otras veces hasta con ánimo de provocar una denegación de servicio. En Robots.txt, todo lo que debería saber y .htaccess, bloqueando a la fuerza tienen dos completos manuales con información sobre como bloquear usuarios perjudiciales.
Verificar bots en una Lista negra
En muchas ocasiones, podemos comprobar si ciertas IPs pertenecen a bots spammers conocidos, y si estos están en algún tipo de lista negra. Por ejemplo, la IP 195.225.177.136 realizaba muchas peticiones en mi servidor. Comprobando la IP en DomainTools vemos que está incluida en la lista negra de spam. Podemos estar seguros de bloquearla.
Formularios
La mayoría de los bots spammers tienen una especial tendencia a sentirse atraídos por los formularios. Especialmente en los comentarios y trackbacks, para hacer publicidad. Muchos, incluso, pueden intentar acceder a formularios que no existen en tu sitio web (sistemas automatizados buscando vulnerabilidades):
grep "POST" access.log | cut -d" " -f6-7 | sort | uniq -c | sort -n
Esta secuencia de comandos te muestra el número de peticiones en las que se hace un POST (comentarios, envío de emails, etc...). Podemos fijarnos, y si vemos algo raro comprobar.
Bots sin/con WWW
Un truco bastante interesante es el siguiente. En mi caso, la dirección principal del blog es www.emezeta.com. Si intentamos acceder a emezeta.com seremos redireccionados al primero. Bien, podemos aprovechar esta característica para descubrir a nuestros «enemigos».
Muchos bots adquieren el nombre del dominio y comienzan a realizar peticiones, incluyendo en su referer la dirección de nuestra página web (en mi caso, sin www) para despistar. Si somos despiertos, nos habremos dado cuenta que es imposible que vengamos de una dirección sin www puesto que habíamos redireccionado.
SetEnvIfNoCase Referer "http://emezeta\.com" bad_bot
deny from env=bad_bot
Solo tendremos que bloquear los referer sin www, como muestra este código.
Esta técnica es bastante efectiva. A mi me ha reducido el spam en un gran porcentaje.
Anti Hotlink para Google Images
La forma en la que Google ha diseñado la búsqueda de imágenes, tiene una característica que puede perjudicar mucho a algunos servidores. No sólo está el problema del hotlink (del que hablamos antes), sino que cuando accedemos a una imagen, nos muestra un marco superior con una miniatura de la imagen, mientras que en el marco inferior se carga la página que la contiene.
La mayoría de los usuarios ni siquiera miran esa página, pero deben pasar por ahí para llegar a la imagen. En Customize Google (extensión para firefox) ya lo pensaron y modifican la página si usas la extensión.
Si a esto añadimos que nos posicionamos en la primera página y primera imagen para búsquedas como perros o Lindsay Lohan, la saturación se puede llegar a notar bastante en servidores pequeños.
Si no nos interesa la indexación de imagenes de nuestro sitio, solo tenemos que bloquear al robot en nuestro robots.txt, pero si en lugar de eso, queremos que no se cargue la página del marco, sólo tenemos que incluir esto:
SetEnvIfNoCase Referer "http://images\.google\..*start" refblock
deny from env=refblock
start es una variable contador que Google incluye sólo en la página intermedia del marco (y no en las finales) y que utilizaremos para bloquear. Luego, si queremos redireccionar a nuestra página principal, en lugar de acceder a la imagen:
RewriteCond %{HTTP_REFERER} ^http://images\.google\. [NC]
RewriteRule \.(jpg|gif|png)$ http://www.pagina.com/ [L]
O bloquearla también:
RewriteCond %{HTTP_REFERER} ^http://images\.google\. [NC]
RewriteRule .* - [F]
Reducir el número de peticiones por página
Otro sistema, también bastante efectivo es el de reducir el número de elementos a cargar en la página principal de un sitio, por ejemplo. Si la página principal de un blog, contiene 45 imagenes (aunque sean iconos) y esta página tiene 7.000 peticiones a su página principal, se van a producir ¡315.000 peticiones diarias!. Todo ello sin contar ficheros CSS, javascript y demás.
cut -d" " -f7 access.log | sort | uniq -c | sort -n
Con esta secuencia de comandos obtendremos la lista de peticiones de ficheros. Prestar mayor atención a aquellos con mayor número de peticiones. Una buena optimización puede mejorar mucho el rendimiento del servidor.
Intentar solucionar las peticiones erroneas
Finalmente, y análogo al caso anterior. Sería bueno intentar solucionar las peticiones erróneas que se producen en nuestro servidor. Una gran mayoría son debidas a problemas externos de buscadores, usuarios que enlazan mal en foros o similares. Pero también puede darse el caso de que nosotros hayamos cometido algún error.
cut -d":" -f4 error.log | cut -d"," -f1 | sort | uniq -c | sort -n Reducir el tiempo de carga de nuestra web
Uno de los detalles que los webmasters y bloggers suelen infravalorar es el tiempo de carga: el tiempo que tarda nuestra página web en cargarse completamente, un factor más que importante.
Un visitante busca acerca de un determinado tema y encuentra nuestra página, y al intentar acceder a ella la página tarda muchos segundos en cargar, automáticamente el lector cerrará la página y procederá a seguir leyendo en otro resultado del buscador que sea más rápido. El tiempo es oro.
Para mejorar la velocidad hay que tener en cuenta muchísimos factores que ya explique por encima en el artículo Conseguir más visitas en tu blog, sin embargo, voy a explicarlo más detenidamente de forma fácil e intuitiva con ayuda de la herramienta Pingdom Tools, que muestro a continuación.
Para empezar, introducimos la dirección de nuestra página web en URL y pulsamos el botón Test now. Esperamos un poco y nos aparecerá un gráfico con un análisis de lo que tarda en cargar nuestra página:
Como podemos ver, es la lista de los ficheros que se descargan al visualizar la página web, junto a su tamaño en Kb (o una flecha verde en el caso de que se obtenga una redirección).
Más a la izquierda, se puede ver una barra de progreso tricolor: amarillo primero, verde después y finalmente azul, interesante por tres motivos.
La barrita amarilla indica el tiempo que tarda el servidor web en atender tu petición. Cuando las barritas amarillas son muy largas, significa que el servidor web no es muy rápido gestionando las peticiones y quizás deberías darles un aviso a tu empresa de hosting (o cambiar si lo ves posible).
La barrita verde proporciona el tiempo que se ha tardado desde que se pidió un archivo desde el navegador y éste empezó a descargarse (primer byte enviado). Es la causa más común de lentitud de un servidor, cuando tiene muchas colas de peticiones se puede ralentizar bastante.
La barrita azul muestra el tiempo efectivo que tardó en descargarse el fichero (desde el primer byte enviado hasta el último). En barras demasiado largas, sería conveniente intentar reducir el peso del fichero para una velocidad mayor.
0-1seg ¡Excelente! ¡Tu web es la caña!. Pero cuidado, puede ser que tu página sea demasiado simple, tampoco te obsesiones con la velocidad.
1-2seg ¡Estupendo! Un resultado más que perfecto. ¡Enhorabuena!
2s-4seg Bien, aunque quizás deberías plantearte revisar la velocidad de carga de tu página.
4s-6seg Regular. Deberías revisar los ficheros incluidos en tu página para reducir el tiempo de carga.
6s-8seg Mal, tu página web tarda demasiado en cargar. ¡Necesitas mejorar el tiempo ya!
Más de 8seg Inconcebible. Ponte manos a la obra.
Una buena táctica para optimizar la velocidad de carga de nuestro sitio es, pulsar en el selector Sort by y seleccionar en lugar de Load order (orden de carga), File size (Tamaño de fichero). Obtendremos la lista de ficheros pero ordenada de mayor a menor en cuanto a tamaño.
Así nos será muy fácil, empezar a revisar desde el fichero que más ocupa (y más probable que tarde en descargarse), y reducir el tamaño en el caso de imágenes (cambiar a formatos preferibles, optimizándolas...), optimizar código en caso de CSS, Javascript o HTML, etc...
A continuación, un listado de actas de un repasito por la Blogosfera, para repartir felicitaciones y tirones de orejas (que nadie se duerma en verano ;)). Recordar que hay muchos factores y esto es sólo es una tabla estimada. Depende de la hora del día (flujo horario alto), si el servidor está sobrecargado de peticiones por alguna referencia o mención, etc...
| Nombre de la página | Tiempo total | Calificación |
|---|---|---|
| Microsiervos | 1.3seg | Notable |
| Sigt | 1.6seg | Notable |
| RubenDomFer | 10.2seg | Insuficiente |
| Marmota mutante | 7.1seg | Insuficiente |
| Telendro | 6seg | Suficiente |
| Inkilino | 26seg | Insuficiente |
| Elaine Marley | 9.2seg | Insuficiente |
| La maté por un yogur | 5.1seg | Suficiente |
| ALT1040 | 1.7seg | Notable |
| Escolar | 3.1seg | Bien |
| Fayerwayer | 5.6seg | Suficiente |
| BlogMundi | 1.9seg | Notable |
| Mangas Verdes | 2.4seg | Bien |
| Pixel y Dixel | 5.9seg | Suficiente |
| 86400 | 12.8seg | Insuficiente |
| Loogic | 4.5seg | Suficiente |
| Tecnochica | 2.2seg | Bien |
| Herramientas para blogs | 19seg | Insuficiente |
| Isopixel | 1.1seg | Notable |
| Minid | 1.2seg | Notable |
| Online | 7.2seg | Insuficiente |
| PuntoGeek | 7seg | Insuficiente |
| Xataka | 11.5seg | Insuficiente |
| MundoGeek | 5.3seg | Suficiente |
| Pitodoble | 8.7seg | Insuficiente |
¿Y a ti? ¿Cuánto te tarda tu página en cargar?
Apagando el PC con una Rube Goldberg Machine
Hace aproximadamente un año, publiqué un artículo en el cuál explicaba lo que era una máquina de Rube Goldberg, «mecanismos» que siempre me han parecido muy curiosos.
Básicamente, se trata de una máquina que hace tareas simples de forma complicada y difícil, y fue utilizada en multitud de ocasiones, desde episodios del coyote y correcaminos hasta anuncios de Honda.
Pero este último, se lleva el premio... Como apagar tu PC con una máquina de Goldberg:
Vía Microsiervos.
La máquina del sueño (Dreamachine)
Hablando con odnei surge el tema de la Dreamachine o Máquina del sueño, inventada por Brion Gysin, escritor y pintor de las afueras de Londres, y por Ian Sommerville, profesor británico ingeniero de software, cerca de los años 60.
Se trata de un curioso aparato formado por un cilindro hueco con una bombilla encendida en su interior. Además, el cilindro posee varios recortes uniformes por donde puede pasar la luz.
Dicho cilindro estaba colocado sobre un gramófono, que gira a una velocidad de 45-75 RPM. Esto hace que se proyecte un parpadeo de luz intermitente, similar al de los ojos en la fase REM y provoque en el observador (que está frente al aparato con los ojos cerrados) un estado de hipnagogia, estado en el que una persona no está ni dormido, ni despierto, sino entre los dos.
Por norma general, se comenta que los observadores de la máquina del sueño (dependiendo de la capacidad de relajación y concentración que tengas) suelen necesitar entre 5 y 10 minutos para que consigan comenzar a soñar despiertos (¡ojo!, ¡hay que estar con los ojos cerrados!), visualizando imágenes u otros. También avisan de que no se recomienda para personas epilépticas o con sensibilidad a desmayos, puesto que el parpadeo constante puede afectarles.
A continuación tienen un manual de como construir una máquina del sueño, una máquina del sueño en versión HTML y un video equivalente al efecto de la máquina del sueño original:
