Google, la todopoderosa, no cesa últimamente en su constante asedio a base de proporcionarnos estudiadas y competentes herramientas que se disfrazan bajo una piel de cordero ofreciéndonos soluciones mientras intentan esconder las obscuras intenciones del lobo más feroz de la red, y estas no son otras que el pago por servicio o SAAS y el absoluto control de cada byte que circula por internet.

Recientemente Google ha mejorado uno de sus servicios más famosos dentro de la comunidad de webmasters y propietarios de páginas web, el sistema de estadísticas y métricas web denominado GA o Google Analytics. La remodelada herramienta de tracking de visitas que nos traen es una muy mejorada funcionalidad para el control sobre el flujo de las visitas que va mucho más allá de lo que nos ofrecía Google Analytics hasta ahora, con un simple vistazo veremos el origen y el camino que conduce al usuario a una acción u otra.

La excelencia de esta optimizada funcionalidad es simple y directa,  la fácil visión del camino seguido por el usuario, un arma muy poderosa si es concienzudamente es aplicada y usada en el análisis de los hábitos del cliente en tiendas virtuales, permitiéndonos maximizar los momentos del proceso de compra: llegada, descubrimiento, interés, confianza y compra.

Si bien esta funcionalidad a día de hoy aún no está presente en todas las cuentas de Google Analytics, pronto será nuestra nueva aliada. Una herramienta que hace que cada día sea más difícil escapar de los largos tentáculos de Google, no hay alternativa, al menos eso creo comparando servicios con servicios.

Os dejo un vídeo para aquellos que aún no tenéis activada esta funcionalidad:

Flujo de las visitas

Páginas relacionadas con este artículo:

1. Clase PHP para leer Google Analytics
2. Google Translate APIsar a los que quieran
3. Google cierra DoubleClick Ad Planner Marketplace

Casi siempre todo funciona bien, el servidor es robusto y responde sin muchas preocupaciones pero el problema llega cuando uno de estos robots se vuelve loco. Seguramente esta locura es producida por algún cambio en alguna variable que fuerza el número de escaneados diarios que realiza el bot, de esa forma el humano “snifante” prueba con diversos valores subiendo a veces sin saberlo la cantidad de peticiones por minuto de forma exponencial, el no ve las repercusiones en el servidor de origen, probablemente se dice, que bien ahora así tengo el contenido nuevo tan pronto como se publica, si soy el primero posiciono mejor, lo voy a dejar así. Y sin saberlo está haciendo un ataque DDOS o de denegación de servicio.

En este caso concreto es tal el consumo que en hora punta de tráfico las peticiones se enletecen hasta más allá de los 3 segundos por página peticionada.

Lo primero es detectar que algo paso, esto por suerte te lo dicen los clientes del servicio web en cuestión con emails técnicos del tipo:

“La web va lenta”, “La web va como el c…”

Recibido el tercer email de este tipo y tras comprobar que no es un problema de la conexión del cliente hacia la red, que también reportan, toca averiguar que está pasando.

1. Vemos el estado de saturación de la máquina. En Windows con el Administrador de Tareas.

2. Lo primero es ver que tal estamos de RAM, que consumo tenemos.

3. Luego vemos el espacio en disco que nos queda

4. El consumo de CPU

5. Ahora vamos a ver con ese mismo administrador de tareas que “programas” son los que más consumen

Si es MYSQL y la RAM va cargada tocará ampliar RAM, al igual de que si es disco.

Si es APACHE y la CPU va saturada, pues tocará ver cuantas peticiones y de quien son recibe el servidor web.

Para conocer cuantas peticiones recibe nuestro server hay muchas cosas y programas, pero en este caso no hay ningún sistema estadístico instalado, bueno si, Google Analytics, el cual pinta y colorea los datos que da gusto, pero a nivel técnico no nos sirve pues estamos buscando excesos y errores y me da a mi que Analytics los obvia, a saber porque con la todopoderosa y sus manías, que ya me cansan.

Aunque no tengamos nada instalado en server siempre nos podemos bajar los archivos de log del Apache para analizarlos en casita, con nuestra maquinita.

Ten en cuenta que estos archivos pueden ser gigantes, depende de como esté configurado el server, los hay con rotaciones y sin, pero puedes encontrartes con archivos de 2Gb. en servidores de alto tráfico, lidia con ellos si puedes. Lo mejor es rotarlos manualmente en el momento de máximo tráfico o ataque.

Para ello, detén el servicio de Apache, renombra los access.log y error.log y vuelve a iniciarlo, dejarás a tu cliente sin servicio un minuto escaso. Aguanta un ratito con el ataque, un par de horas a lo sumo, y vuelve a hacer lo mismo, de esa forma tendrás una muestra sanguínea del ataque o del momento de saturación del server y trabajarás única y exclusivamente con esos datos, localizando más rápidamente si existen direcciones IPs que un consumo excesivo de datos.

De Windows a Ubuntu y tiro porque me toca

Una vez muevas ese log a una carpeta accesible por FTP o HTTP faltará bajártela para analizarla en tu flamante workstation Ubuntu, que mola más que un OS X… al menos más que un Snow Leopard, pues falta ver si este próximo lunes día 6 de Junio lo que nos maravilla OS X Lion de la mano de Steve Jobs, palabra de AppleFun arrepentido venido a Ubuntu.

Analizando los archivos .log de Apache

Para analizarlo en nuestro Ubuntu vamos a usar Webzilla, para instalártela:

sudo apt-get install webalizer

Luego la configuramos con un:

sudo gedit /etc/webalizer/webalizer.conf

Aquí en principio sólo falta tocar el lugar, ruta y archivo donde está el access.log

LogFile                   /var/www/logs-para-analizar/access.log
OutputDir              /var/www/webalizer
Incremental           yes

Grabamos y ejecutamos el Webalizer con un complejísimo, es broma:

sudo webalizer

Unos segunditos y tachán, apunta tu navegador a:

http://localhost/webalizer

Selecciona el mes actual, y en la siguiente pantalla la opción “Clientes” aquí verás las IPs que han visitado más la página durante el ataque o la bajada de rendimiento del server, busca las más abultadas que vamos a revisarlas.

Ahora nos faltará saber el Quién es quién de cada IP

¿Quién es quién?

Para eso podemos usar varias opciones, entre ella una via web:

http://whois.domaintools.com/67.195.112.52

Donde 67.195.112.52 es la IP sobre la que quieres conocer información y la otra es usar las herramientas de red del sistema que incorpora Ubuntu.

Con ellas puedes realizar un WHOIS, un LOOKUP , etc.

Si entras en “Explorar los puertos”, cosa que tarda un rato podrás también detectar si detrás hay un servidor web, un servidor FTP, o un emule abierto. Datos que te permitirán determinar con algo más de certeza si se trata de una empresa o un usuario.

También puedes rastrear la ruta para más o menos ver de donde es el país de origen, si este por ejemplo es de Ukrania o de la conchinchina probablemente se trate de un buscador en el que no te importe perder posicionamiento.

Cuidadín cuidadín con los GoogleBots y familia

Pues eso, asegúrate que de todas esas IPs no te apuntes ninguna que sea de un buscador conocido en el que te quieras posicionar, pues si la anotas y luego la baneamos perderás el posicionamiento en ese buscador pues tu Apache no le dejará entrar.

Ya tenemos las IPs localizadas y correctamente anotadas, ahora vamos a banearlas

Baneando IPs en Apache bajo Windows

Bueno esto a decir verdad es más o menos igual en Windows que en Linux que un radiocassette donde sea capaz de correr Apache.

Busca el fichero de configuración de Apache httpd.conf

En la sección Directory

Introduce al final, justo antes del cierre de la directiva </Directory> y una en cada línea la siguiente instrucción:

deny from TU-NO-PASAS

por ejemplo si quisiéramos banear a Yahoo, NO lo hagas!

deny from 67.195.112.52

Graba el fichero y reinicia Apache, en Windows desde “Accesorios -> Herramientas del Sistema -> Servicios -> Apache” botón de la derecha reiniciar.

Listas negras de IPs malignas

También de paso y por el mismo precio que nos ponemos a banear, una práctica aceptable sería el banear sistemáticamente aquellas IPs que se han detectado en el mundo recientemente como IPs malignas.

Yo he sacado una lista desde:

http://isc.sans.org/ipsascii.html

y desde:

http://isc.sans.org/sources.html

Baneando que es gerundio.

Páginas relacionadas con este artículo:

1. Test de carga web
2. Personalizar un virtual host de Apache bajo Plesk
3. Bloquear muchos intentos fallidos de acceso a servidor

Con este comandito podrás hacer un backup en un fichero de texto de las bases de datos en servidores remotos a la máquina donde ejecutes el “comandito”:

mysqldump -h direccion_ftp_remoto –password=claveRemota –user=usuarioRemoto nombre_base_de_datos_remota –routines> /home/backup/mysql-servidor_talytal.sql

Hay otras combinaciones de este efectivo comando de Mysql, por ejemplo este que me sirve para realizar copias de una base de datos de un servidor a otro:

mysqldump –host=direccion_host_origen –password=clave_mysql_origen –user=usuario_origen tabla a copiar | mysql –password=clave_mysql_local –user=usuario_mysql_local tabla_destino

La tabla de destino tiene que existir, es indiferente si tiene datos o no, o si las estructuras son diferentes pues mysqldump la machacará con los datos que vienen del origen.

Además podrás despreocuparte un poquito de tus datos si añades esta copia a una tarea con cron para ello haz un:

sudo crontab -e

Y métele algo así como:

00 21 * * * mysqldump –host=… y toda tu comando

Esto copiará la tabla todos los días de la semana a las 21.00H.

Páginas relacionadas con este artículo:

1. Optimizar bases de datos Mysql
2. Optimizar bases de datos Mysql
3. Cambiar clave root a Mysql por línea de comandos Windows

http://www.db.ripe.net/whois?form_type=simple&searchtext=IP

Sustituye la IP por el numerito que te trae de cabeza y te dirá donde está alojada esa web, es válido para los .es

Esto sirve por ejemplo para decir, si quiero migrar de ISP y a mi competencia le va bien o le va mal vamos a investigar, y de esa forma podemos descartar unos cuantos proveedores, que los hay muy malos, todo hay que decirlo.

Páginas relacionadas con este artículo:

1. Saber el uptime en Windows
2. Saber el uptime en Windows
3. Medir la velocidad de una web

Esta aplicación web te ofrece los siguientes resultados:

• Capturas con los diferentes momentos en el proceso de descarga de la web
• La posibilidad de medir la velocidad de la misma desde diferentes países
• La posibilidad de medir la velocidad bajo diferentes navegadores web
• La gráfica con todos los archivos que conforman la página, su peso y su velocidad de descarga

Una de las limitaciones que presenta esta útil utilidad para medir la velocidad de descarga de una web es que tan sólo te permite realizar un máximo de 50 checks diarios bajo la misma IP, en la práctica creemos que son menos pues hemos intentado monitorizar la aplicación de facturación online invOOice.com desde todos los países que permite y tan sólo hemos podido llegar a medir 15 países.

La principal conclusión que he podido extraer, y que ya era obvia pero no tan mesurable, es que un servidor alojado en USA es mucho más rápido si es visitado desde la propia USA que desde Europa. Toma obviedad! Las diferencias que me he encontrado son muy muy destacables, del orden de los 9 segundos para una página home con tan sólo un formulario de login de usuario y unos cuantos enlaces, todo con el grafismo, el javascript y el html pesa un total de 103,6 Kb. que por lo que veo, se puede y debe optimizar.

En la gráfica Waterfall, que es la que te indica cuanto tarda cada archivo en descargarse veo claramente que puedo minimizar bastante, pues existen un total de 12 peticiones request y hay algunos archivos que no son estrictamente necesarios o son minimizables en esta pantalla pues el usuario aún no está logueado, si los elimino podré optimizar y mucho la velocidad de descarga de esa primera página o página home, también simultáneamente podré mejorar la seguridad del sistema. Un ejemplo claro es la hoja de estilo que se carga, que es la hoja de estilos de la aplicación, cargarla toda para tan sólo un login quizá no tiene mucho sentido. por lo que se puede reducir mucho si se carga una con tan sólo los elementos que se utilicen, o mejor alguno, al ser pocos si los mismos se incrustan en el tag HEAD se gana una petición request menos.

Otro punto a destacar es que obviamente las imágenes son siempre lentas y pesadas, por lo que también toca optimizarlas, siempre sin sacrificar la calidad ni la imagen que se quiere dar al aplicativo.

A continuación los resultados del test del sistema de facturación web http://invOOice.com para cargar la página de inicio o home, hay que indicar que el servidor de invOOice.com está ubicado en USA y los resultados son, por orden de mayor lentitud a mayor velocidad de descarga:

1. Visitante de Guadalajara (México) que visita invOOice.com: 10.27s
2. Visitante de Ciudad del Cabo (South Africa) que visita invOOice.com: 5.04s
3. Visitante de Nagano (Japón) que visita invOOice.com: 4.16s
4. Visitante de Río de Janeiro (Brasil) que visita invOOice.com: 3.57s
5. Visitante de Cairo (Egypt) que visita invOOice.com: 3.19s
6. Visitante de Sydney (Australia) que visita invOOice.com: 4.16s
7. Visitante de Madrid que visita invOOice.com : 2.84s
8. Visitante de Inglaterra que visita invOOice.com : 2.66s
9. Visitante de Zurich (Suiza) que visita invOOice.com : 2.64s
10. Visitante de Vancouver (Canada) que visita invOOice.com: 2.27s
11. Visitante de Florida (USA) que visita invOOice.com 2.25s
12. Visitante de Austin (USA) Chicago (USA) que visita invOOice.com 1.88s
13. Visitante de New York (USA) que visita invOOice.com 1.80s
14. Visitante de Dallas (USA) que visita invOOice.com: 1.78s
15. Visitante de San Francisco (USA) que visita invOOice.com 1.66s

Las diferencias son de bulto más de 1 segundo entre San Francisco y Madrid, eso en este caso es el doble, además parece que además de la cercanía física de la conexión en relación al servidor alojado en USA también influye la calidad de las conexiones de internet de cada país, de lo contrario no se explicaría que el más lento fuese México cuando en kilómetros la distancia es quizá la menor, es decir, la conexión más cercana con el servidor, a parte, obviamente de la de San Francisco.

Destaco también las diferencias dentro de la propia USA, del orden de 3 décimas de segundo de una costa a otra.

Esperamos poder sacarle una constatable mejora de velocidad a nuestros sistemas, así como la correspondiente mejora en posicionamiento, pues Google valora, y mucho, la velocidad, y todo ello gracias a esta aplicación web, ya no sólo desde el punto de vista de la optimización de los contenidos web si no más bien a través del uso de CDN o Content Deliverable Networks y a través de sistemas Clouds descentralizados, que te permiten crear nodos o clústers de tu aplicación web en diferentes localizaciones, países o continentes.

Si alguien de vosotros, lectores, conoce otros sistemas alternativos para medir la velocidad de descarga de una página web, que no lo dude, que nos deje un comentario, entre todos mejoramos.

Páginas relacionadas con este artículo:

1. Comprobar la velocidad de carga de una web
2. Comprobar velocidad servidor
3. Test de carga web

Muchas de estas aplicaciones ya las conocía, pero de todas, me quedo con http://loadimpact.com/

Sencillamente porque su versión gratuita te permite simular hasta 40 usuarios navegando simultáneamente en tu página web, cifra más que suficiente para poder medir cualquier hosting y predecir si se va a caer.

Para los programadores web tiene otra utilidad, la de la optimización, sí ya sabes que arañar unos bytes a tu código siempre le sienta bien, pero bueno, ¿tan poco se nota? Dedicar 4 horas depurando para unos pocos bytes es rentable. Si te lo pagan sí. Por ejemplo en aplicaciones críticas con muchos usuarios concurrentes quizá el primer paso es optimizar y no proceder a cambiar de hosting o de servidor con elcoste que implica.

Esta prueba de rendimiento en masa tiene otras aplicaciones, no sólo podrás saber si el hosting que tienes o el de tus clientes es bueno sino que también si eres de sistemas te permitirá comprobar la eficacia en cuanto a rendimiento de los cambios de configuración que realices en la configuración de un servidor. Incluso ir un paso más allá, podrás medir diferentes servidores web, Apache bajo Windows, Apache bajo Linux, Nginx, Cherooke…

Bueno pues nada, a optimizar nenes y nenas de la web!: http://loadimpact.com/

Páginas relacionadas con este artículo:

1. Comprobar la velocidad de carga de una web
2. Nginx y phpMyAdmin
3. Baneando direcciones IPs en Apache bajo Windows

http://www.hongkiat.com/blog/website-speed-and-performance-check-tools/

Páginas relacionadas con este artículo:

1. Optimizar la velocidad de descarga de una web
2. Comprobar velocidad servidor
3. Test de carga web

Hoy hemos recurrido a una utilidad web para comprobar la velocidad de un servidor web desde diferentes países del mundo.

La utilidad se denomina Host Tracker y la puedes encontrar en: http://host-tracker.com/

Es tan fácil como introducir la URL de la página a comprobar y esperar un tiempo, bastante por cierto, pero el sistema es muy completo te realizaré el test desde muchos países, en nuestras pruebas realizadas a finales de Julio del año 10, (2010) el sistema chequea desde 95 puntos diferentes, ofreciéndote resultados sobre el país de origen así como del nombre del servidor colaborador que ha realizado el test, el tiempo de descarga conseguido de la página solicitada, velocidad de transferencia, IP destino de la página solicitada, pues si depende del tipo de servicio si esta está balanceada pueden responder diferentes IPs cuando tienes configurado un sistema de balanceo de carga por país.

Todos estos datos te los ofrece de forma individual además de darte los valores medios para que tengas una valoración global de la velocidad de tu servidor.

Páginas relacionadas con este artículo:

1. Comprobar la velocidad de carga de una web
2. Medir la velocidad de una web
3. Test de carga web

Si ayer te traíamos una chuleta con las compatibilidades de CSS3 con la mayoría de navegadores modernos hoy te traemos otra nueva chuleta pero esta vez con el listado de compatibilidades de HTML5 bajo esos mismos navegadores.

Páginas relacionadas con este artículo:

1. Compatibilidad del HTML5 entre navegadores
2. Compatibilidad CSS3 con diferentes navegadores
3. El aporte que HTML5 representa a los desarrolladores web

Un apunte ultrarápido que nos permitirá saber que aplicaciones y que usuarios están consumiendo más recursos en tu máquina, esta funcionalidad es válida tan sólo para máquinas Linux o basadas en Unix, se trata del comando top.

Abre una terminal e introduce el comando: top

Te aparecerá una pantalla como la que te mostramos en nuestra captura,mostrándote ordenadas las aplicaciones o procesos de mayor a menor consumo de recursos, en nuestro caso lo que más está consumiendo es Firefox (tenemos más de 15 pestañas abiertas), con un 32% de la cpu y un 6,4% de la memoria RAM. Vemos curiosamente que XORG, la interficie gráfica que incorpora Ubuntu utiliza un 1% escaso, a la que hay que añadir Compiz con un 1,4% gt-window con un 0,3% y gnome-panel con un 0,9 total, que tenemos una interficie gráfica de las de quitar el hipo, gestionando 2 pantallas de diferente resolución y un total de 4 escritorios virtuales sin pestañear, una interficie superior en muchos aspectos a la de Mac OSX (nuestro exposé es bastante mejor) .

Este comando en principio no requiere permisos de superusuario.Si bien si quieres ver el consumo de procesos que corren bajo root, como Apache o Mysql deberás ejecutarlo como superusuario, así que casi mejor que lo ejecutes como “sudo top”  (te pedirá clave)

Ideal para monitorizar servidores basados en Linux a los que tengas acceso mediante SSH. Así que apunta hacia tu servidor virtual, tu servidor privado y a monitorizar para ir optimizando, que es gerundio.

Páginas relacionadas con este artículo:

1. Saber el uptime en Windows
2. Test de carga web
3. Base de datos Cassandra