Credit image

¿Te gusta el diseño web? ¡Echa un vistazo a la documentación de LenguajeCSS.com!

Reducir uso de CPU y memoria del servidor

Varias técnicas para reducir el uso y consumo de CPU y RAM en servidores web, restringiendo el tráfico (hotlinking) a ciertos sitios, visitas de bots de spam, etc...

¡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

Escrito por Manz, el , en webmasters. Comentarios recibidos: 17.

17 comentarios de lectores
Tankian
Tankian
1

Pfff, yo creo que si hago todo eso... las visitas se reducirían un 95% (el otro 5% son visitas mías xD) Bromas aparte, muy currado el artículo, se ve que los spammers cada vez te traen mas de cabeza.

Lean Lee
Lean Lee
2

Muy buen articulo. Debes consumir mucho ancho de banda por mes imagino, se puede saber cuanto estas consumiendo al mes de trafico?

Abel
Abel
3

Muy buen artículo, y aunque no tenga mucho qué ver, creo que faltó hacer hincapié en dos cosas, optimizar las consultas a las bases de datos y cuidar el tamaño de los archivos para efectos de minimizar ancho de banda. Cuando usamos bases de datos siempre debemos cuidar la memoria que usamos para las consultas y una vez que terminemos de usar los resultados y antes de que finalice el script, hay que liberar esa memoria y cuando sea necesario, cerrar las conexiones. Para cuidar el ancho de banda hay que tener una buena estructura de nuestro XHTML y separarlo completamente de los estilos CSS y las funciones JS. Esto último no es estrictamente necesario para optimizar CPU y memoria del servidor, pero lo de las consultas sí.

Manz
Manz
4

Lean Lee, el ancho de banda es algo que siempre he tenido controlado, puesto que empecé con un servidor local casero y una conexión ADSL. Había que controlar el AB en todo momento. Abel como bien dices son dos cosas bastante importantes. Respecto a optimizar las consultas de las bases de datos, es un tema muy importante. Es bueno dejarlo abierto para un próximo artículo... ;)

Armonth
Armonth
5

Buen artículo, y en lo que respecta a lo de bloquear el hotlinking en los foros gracias, es algo que tenia pendiente pero no tenia tiempo de ponerme a mirarlo. Sobre lo que dicen de base de datos, quizá os interese un artículo que escribí hace poco sobre optimización del servidor MySQL (principalmente) y pensando en WordPress (secundariamente) :)

thecatnegro
thecatnegro
6

gran articulo

InKiLiNo
InKiLiNo
7

Genial articulo, necesitaba alguna de las cosas que comentas para mi servidor ;)

magacín66
magacín66
8

Como siempre, información interesante y necesaria. Gracias!

Andrew Mitnik
Andrew Mitnik
9

Disculpa Manz, ¿puedes compratirme cómo hiciste para tener un server con aDSL? Digo, rutear sé, instalar server y todo eso, pero, cómo hiciste para controlar el ancho de banda? No me lo explico. Gracias por el artículo

Manz
Manz
10

¿Porque no, Andrew Mitnik? Es lo más sencillo. Tendrías que controlar el ancho de banda de subida en todo momento, ya mediante el router, o mediante algun programa externo (NetLimiter es una estupenda opción). No entiendo muy bien la duda que tienes, comentamela y encantado de responderte.

Alex
Alex
11

Yo le incluiría Wordprexy.com :p

jorge-lokillo
jorge-lokillo
12

como puedo bajar mi uso del cpu ?? (esta al 100% y sin abrin nada de nada) plis respondame cuanto antes gracias ;)

Aimbox
Aimbox
13

Me parece que este tutorial va mas orientado a disminuir el ancho de banda utilizado, no la Memoria o CPU

Manz
Manz
14

@Aimbox: Efectivamente, está orientado a disminuir el ancho de banda utilizado. En la mayoría de los servidores de hosting que utilizamos (sobretodo en compartidos con overselling) ofrecen cantidades muy altas o ilimitadas de ancho de banda, haciendo ver que no hay que preocuparse por esos detalles. El truco está en que cuándo el tráfico es muy grande, los procesos dedicados a servidores web están muy ocupados atendiendo peticiones, aumentando el consumo de CPU/RAM del mismo. Es aquí donde se suelen recibir los avisos de las compañías de hosting avisándonos que por exceso de consumo de CPU te pueden cerrar la cuenta.

jhomar
jhomar
15

en un servidor de 1 gb de ram con solo una web ya se me esta saturando el servidor, apenas que esta web tiene como media 1500 visitas diarias, segun el manager del vps dice que es un robot de google que consume toda la ram, lo veo dificil un robot solo es como si fuese un usuario mas, de todos modos intento mejorar el uso de la memoria, y tus post me ayudo un poco, gracias.

fernando
fernando
16

wow acabo de probar esto y me da un resultado demasiado elevado Memoria usada: 24576.1 KB de 25088 KB con plugin Memoria usada: 22466.8 KB de 22784 KB sin plugins tengo wordpress con un theme que yo mismo he realizado pero el rsultado me ha sorprendido no se porque usa tanto si mi blog es relativamente nuevo 2 meses debe tener unas 30 o 40 entradas.Alguien que me podria ayudar se lo agadeceria mucho

juancho
juancho
17

que buen articulo me sirvio mucho para mi web gracias

Publica tu opinión

Si lo deseas, puedes utilizar el siguiente formulario para publicar tu opinión o responder a alguna de las existentes:

Previsualización

Aquí se previsualizará su comentario. Revise que sea correcto antes de publicarlo.