Artículo patrocinado
Handy Recovery es una de las tantas aplicaciones de software de recuperación de archivos o ficheros eliminados que existen en el mercado. Sin embargo, este destaca de los demás por su extrema sencillez y efectividad.
El programa Handy Recovery funciona perfectamente en cualquier generación anterior de Windows (Windows 95, Windows 98, Windows ME) o actual, basada en sistemas NT, (Windows 2000, Windows XP o el nuevo Windows Vista) y permite recuperar archivos eliminados de particiones con los siguientes sistemas de archivos:
Una vez instalado y ejecutado, veremos una pantalla similar a la siguiente, con una interfaz muy sencilla y simple:
En el primer menú podemos encontrar opciones como Seleccionar disco o partición... donde podremos seleccionar la unidad de disco duro, tarjeta de memoria o similar para buscar ficheros. También nos permitirá Abrir una imagen del disco (que hemos salvado en otra ocasión) para no depender del medio físico.
Una opción adicional de Búsqueda de particiones pérdidas permite buscar desde sectores del disco que no contienen información actualmente.
El programa principalmente, incorpora dos métodos. Un primer análisis rápido, que busca ficheros eliminados en la partición o espacio seleccionado, y un segundo método exhaustivo Análisis ampliado, que busca en profundidad toda la información perdida que pueda recuperar, teniendo en cuenta ciertas restricciones o características como la naturaleza de los ficheros a recuperar:
Handy Recovery incorpora un sistema de búsqueda y filtrado de archivos, donde podremos descartar ficheros una vez encontrados (existentes, con cierto tamaño, fecha de modificación, etc...).
Si no quieres complicarte con demasiadas opciones y características con programas de este tipo, probablemente este software se convertirá en uno de tus favoritos.
Después del manual para reducir el consumo de CPU y memoria RAM del servidor, seguimos con los consejos para optimizar nuestro servidor. Uno de los aspectos que más debemos cuidar es el uso de memoria RAM que hacemos a medida que se ejecutan nuestros scripts.
Cuando los visitantes acceden a nuestras páginas, la ejecución de los scripts PHP (o Perl, Ruby...), las consultas SQL a la base de datos, la optimización de la programación y otros factores ayudan o perjudican en el uso de memoria RAM. La mayoría de las veces no tenemos ni idea de cuanta memoria estamos utilizando en cada petición de página, pero vamos a averiguarlo.
echo 'Memoria usada: ' . round(memory_get_usage() / 1024,1) . ' KB de ' . round(memory_get_usage(1) / 1024,1) . ' KB';
echo 'Memoria usada: ' . round(memory_get_usage() / 1024,1) . ' KB';
Con este código PHP (sólo en PHP 4.3.2 o superior) obtendremos la cantidad de memoria que está consumiendo por petición nuestro blog o página web. Pero puede ocurrir que nuestro sistema no esté compilado con esta opción, para ello podemos utilizar la siguiente función. Obviamente, necesitaremos
function memory_get_usage() {
$pid = getmypid();
exec("ps -o rss -p $pid", $output);
return $output[1] *1024;
}
En muchos casos nos resultaría más útil guardar en una variable (recuerda, no debes usar echo al principio si envías cabeceras, obtendrás un error) el consumo de memoria que hay al principio del script:
$mem_inicio = round(memory_get_usage() / 1024,1);
Así, más tarde lo podríamos imprimir por pantalla para compararlo con el consumo final y conocer el verdadero gasto del script, ya que el consumo final puede estar debido a razones «anteriores» a la petición del script, como el uso del mod_rewrite, gestión de los procesos del apache y muchos otros criterios.
Date cuenta que esta es una buena forma de ver cuánto está consumiendo por petición nuestro Wordpress (o cualquier otro CMS). ¿Y tu blog cuánto consume por petición?
¡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:
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.
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.
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.
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.
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.
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]
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.
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 -nHace ya varios días, recibía una llamada telefónica de mi pingüino operador, desde la central principal de Emezeta. Me comentaban que mi servidor compartido (alojado en Dreamhost) estaba echando humo y que la docena de pingüinos de la central no daban abasto debido a las peticiones que estaba recibiendo la web, así que en ciertos momentos colocaban una foto estática de la sala de juntas:
Es por ello que, junto a mi pingüino CEO, hemos decidido contratar un VPS (basado en Linux-VServer), el nuevo servicio de Dreamhost: Dreamhost Private Servers.
Cotufa Server es nuestro nuevo servidor. Una potente máquina virtual-dedicada, a cargo de la dirección de 20 pingüinos que intentarán que los lectores de Emezeta no tengan ningún problema al acceder al servidor.
Fuera bromas.
Hace algunos días, comencé a observar que mi página mostraba algunos errores 500 (error interno del servidor) o 503 (servidor temporalmente no disponible). Estos errores son muy poco específicos, así que para saber exactamente la causa, nada más fácil que acceder al log de errores (normalmente error.log).
En mi caso, pude ver algo similar a lo siguiente:
access to / failed for 80.xxx.xx.xx, reason: Client exceeded concurrent connection limit of 20
El motivo de los errores era la concurrencia, es decir, ejecutar simultáneamente un cierto número de peticiones. Al parecer, Emezeta estaba superando un limite de 20 peticiones simultáneas, y en esos momentos el servidor mostraba un error.
Me puse en contacto con Dreamhost y me comentaron que el criterio de sus servidores compartidos era el de no permitir más de 20~30 peticiones concurrentes para garantizar el buen funcionamiento del servidor.
Me pareció razonable. Ya que el precio del servidor es bastante económico, no veía lógico el perjudicar a otros usuarios de mi servidor, así que muy amablemente me ofrecieron una invitación a su nuevo sistema VPS: Dreamhost Private Server, el cuál estoy empezando a utilizar y funciona muy bien.
No obstante, no todo iba a ser tan fácil. Ampliar los recursos del servidor, sin optimizar al máximo el consumo de CPU y memoria RAM sería un gasto superfluo de recursos. Así que, manos a la obra.
En el siguiente artículo explicare como reducir el consumo de CPU y memoria basándome en mis propias experiencias, por si le sirve de ayuda a alguien.
6 consultas efectuadas / Página generada en 0.037 segundos
Programado íntegramente por José Román (Manz) en XHTML y CSS estándar.
Sindicado bajo Feed RSS. Contenido bajo licencia Creative Commons
Estadísticas de visitas · Términos y condiciones · Contacto · Publicidad · Preguntas frecuentes (FAQ)