Curated by: Luigi Canali De Rossi
 


7 July 2006

Servidor Lento: Las Causas Pueden Ser Comentarios, RSS, Cron Y MSNbot

¿Su servidor está más lento y esto le ocasiona problemas? Si usted, como yo, es un pequeño editor independiente online, perder tráfico regular sabiendo que la causa no es que sus lectores están yendo a mejores destinos, puede ser algo tan frustrante como intentar retener el agua con las manos.

Si su servicio de monitoreo de tráfico en tiempo real le muestra descensos repentinos y números de visitantes completamente fuera del promedio en determinado momento del día, usted sabe que hay algo en su servidor que no está funcionando correctamente.


spider_web_id181242_size450.jpg
Photo credit: Linda Bucklin

Poder descubrir lo que está sucediendo realmente, requiere la habilidad y la paciencia de un diestro webmaster que tenga la suficiente perseverancia y experiencia para descubrir las ocultas arañas de la web que visitan su sitio en Internet. Hallar que es lo que tiene culpa no siempre es un asunto sencillo y en algunos casos, especialmente cuando pueden ser múltiples los factores que estén en juego, hallar una solución puede llevar hasta varios meses.

Eso fue lo que me sucedió durante los últimos seis meses.

Ya sea que esto muestre lo tonto que hemos sido o cuántas pueden ser las causas de su propio infortunio, no me avergüenza compartir mi historia ya que espero poder ayudar a otros editores online como yo a que eviten desperdiciar tanto tiempo, recursos y dinero.

 

Comencé a notar repentinos descensos en el tráfico de mi sitio principal www.masternewmedia.org hace algunos meses,
y si bien el tráfico en general seguía creciendo como en el pasado, no podía dejar de preguntarme a que se debían esos bruscos y relativamente breves descensos.

Hitbox_traffic_dip_intermittent.gif

Conjuntamente con mi webmaster Drazen D., comenzamos inicialmente en enfocarnos en Movable Type la cual es la plataforma de publicación personal que hemos estado utilizando para mantener todos nuestros sitios
web. Pensamos que el proceso de reconstrucción era el culpable y por lo tanto nos concentramos en reconstruir la arquitectura de todas las plantillas de las páginas del sitio para reducir significativamente la carga del lado del servidor cada vez que éste necesitaba reconstruir una o más páginas.

El tema en este caso era bastante real y más tarde descubrimos que contribuyó significativamente a la resolución de nuestros problemas de pérdida de velocidad del servidor. En masternewmedia.org tenemos muchas páginas de "categoría de contenido" y "tag" las cuales recolectan toda la historia de nuestro sitio de todos los artículos debajo de diferentes y algunas veces múltiples categorías. Entonces cada vez que se publica un nuevo artículo, el proceso realizado por el sistema de publicación para actualizar todo este archivo y las páginas de tag/categorías puede ser bastante intimidante.

Pero una vez que solucionamos esto, vimos que los problemas del servidor iban a retornar y sin menguar su poder.

Hitbox_traffic_dip.gif
Repentina caída en el tráfico - esos son síntomas de un comportamiento anormal - sirve que está sucediendo con frecuencia algo no está funcionando bien en el servidor


Por lo tanto, aunque recomendaría absolutamente a cualquiera en mi posición que se preocupe seriamente en tener un arquitectura de plantillas de páginas que sea altamente modular y bien diseñada (la mía fue el resultado de un largo proceso de parchado, lo cual hizo más daños que beneficios) también el tráfico del sitio, el acceso a las páginas y la posibilidad de que los usuarios tuvieran una experiencia positiva del sitio estaba afectado. Puedo afirmar esto porque, paralelamente con las disminuciones de tráfico en determinados momentos del día (difíciles de detectar a menos que lo monitoree varias veces por hora), también eran apreciables las caídas en las ganancias de AdSense. Esto es la posibilidad que tienen las personas o el éxito en la tasa de lectura y cliqueo sobre información comercial relevante: nuestra principal fuente de ganancia.

Luego estaban los "comentarios y trackbacks".

Debido a la sobreexplotación que comerciantes malintencionados utilizan actualmente, las funciones de comentarios y trackback de cualquier blog o sitio de noticias que esté basado en un "motor de blog-publicación personal" se ha convertido en un imán irresistible para los peores comentarios y trackbacks spam que usted se pueda imaginar.

Pero lo peor de todo es que esos comentarios y trackbacks a menudo están operados por "bots" de software automáticos, los cuales pueden empezar a escupir ríos de enlaces a sitios ilegales a una tasa de centenares por hora.

Encontrar formas para manejar efectivamente las prestaciones de filtrado de comentario spam para filtrar, disuadir o incluso evitar este tsunami de pura basura es en ocasiones demasiado difícil para las personas involucradas y la solución que muchos han tomado ha sido simplemente es habilitar esas prestaciones haciendo imposible para los usuarios normales colocar comentarios o enviar trackback pings a sus envíos y por lo tanto inhibiendo uno de los a menudo rasgos fundamentales de la revolución de nuevo medio que está teniendo lugar online: el aspecto conversacional.

Para nosotros esto ha sido una persistente piedra en el zapato, hasta que hace algún tiempo finalmente lo domesticamos. O por lo menos lo hemos bajado a un nivel que limitaría de alguna forma los efectos negativos en los recursos de nuestros servidor. Logramos esto haciendo exactamente lo que he escrito más arriba. Hemos inhibido, frustrado y exasperado a centenares de individuos inocentes que estaban muy interesados en colocar un comentario MasterNewMedia.org, haciendo imposible, inútil, enviar un comentario cuando estamos probando detener esa ola de basura. No hemos sido muy inteligentes al no informar a los usuarios de esta situación y por lo tanto alienar a muchos de ellos, los cuales erróneamente pensaron que yo era desprolijo o no estaba interesado en tener un diálogo verdadero, abierto con mis lectores.

Pero incluso ahora que la gente difícilmente puede comentar en este sitio y que muchos de estos motores de comentarios spam comenzaron a ver que sus esfuerzos con mi sitio son bastante inútiles, las "caídas" en el servidor continúan apareciendo.

Así es como se ve el tráfico en un sitio saludable cuando el servidor está haciendo su trabajo correctamente, libre de otros factores:

Hitbox_traffic_normal_upward_trend.gif

No estoy diciendo que corregir y mejorar las plantillas y comentarios/trackback spam no nos hayan traído mejoras y beneficios. Lo hizo y de manera positiva. Pero todavía puedo ver que en momentos específicos y algunas veces por algunas horas, nuestro servidor dedicado (hospedado en Pair.com en Pittsburgh)
estaba severamente disminuido por algo que aún no podíamos identificar.

Luego en nuestra lista estuvimos fijándonos en alimentadores RSS y las demoras causadas cuando necesitábamos obtener contenido de un servidor externo y este otro servidor estaba sobrecargado por algún otro problema. Dado que yo hago un uso intensivo de los alimentadores RSS y traigo mucho contenido de los otros sitios que administro y edito, tuvimos que encontrar algunas soluciones para aliviar todo el agregado, parsing y generación de RSS que por momentos hacía que nuestro servidor se arrastrara.

Utilizar un proveedor de servicios externos (o un segundo servidor dedicado con un software personalizado para administrar noticias como los que proporcionan MySyndicaat y Newsgator) para administrar grandes cargas de contenido RSS entrante es la mejor opción y vimos una mejora considerable cuando abandonamos el memorable motor Carp que estaba corriendo en nuestro servidor a favor de una granja de servidores externos de alto rendimiento provisto por MySyndicaat.

RSS caching es también un paso importante que hay que tomar para de esta forma reducir el consumo total del ancho de banda y la carga sobre el servidor. Con el denominado "RSS caching" usted básicamente almacena por algún tiempo predefinido el contenido de todos sus alimentadores RSS, en vez de estar realmente yendo a buscar cada alimentador RSS toda vez que un visitante invoca a una de sus páginas integrando el contenido que proviene de un alimentador RSS. Dicho contenido es almacenado digamos cada hora, permitiendo que la página cargue mucho más rápido haciendo que su cuenta de uso del ancho de banda sea mucho más eficiente.

Pero tampoco era a causa del RSS.

Hitbox_traffic_dip_long2.gif

Empezamos entonces a monitorear el servidor con mayor detenimiento e intentamos identificar exactamente los scripts, procesos cron y tareas que estaban sucediendo cuando las estadísticas de tráfico mostraban una "caída".

Drazen encontró procesos cron que no había necesidad de mantenerlos vivos, scripts desconocidos ya sea configurado por alguien en el pasado o ubicados formalmente por el proveedor de Internet el cual monitorea y atiende tareas técnicas específicas. Suspendimos, borramos, suprimimos y removimos todos y cada uno de ellos hasta que no estuvieron más.

Pero tampoco los procesos CRON y otros scripts del servidor lo hicieron.

No queríamos abandonar pero nos dimos cuenta de que algo nos estaba desconcertando.
Parecería que no estábamos buscando en los lugares correctos.

Y de hecho, el problema con nuestra metodología para solucionar los problemas del servidor era que estuvimos mirando todo el tiempo en la dirección equivocada.

¡El problema no estaba en el servidor!

¡El problema estaba con un usuario!

¿Un usuario?

Sí, un usuario. Esta es su foto:

robot_spider_id91259_size400.jpg
Mi idea imaginaria de MSNbot, la araña que puede reducir drásticamente la velocidad de sus servidor, a menos que administre su archivo robotx.txt de manera adecuada - Photo credit: Michael Osterrieder

El MSNbot es una araña web que explora los sitios web con el mismo propósito que sus similares de Google o Yahoo: indexar el contenido de su sitio web para llevárselos de vuelta a "casa" al motor de búsqueda MSN y otros servicios relacionados.

Pero el MSNbot aparentemente es menos educado, cortés y discreto que cualquiera de las arañas de los otros motores de búsqueda principales existentes. A partir de mi propia investigación al respecto, el MSNbot es especialmente vulnerable a situaciones como la mía en la cual, un sitio con algunos miles de páginas, publica listas de alimentadores RSS de categorías de artículos relacionados, sitios y más, mientras que el MSNbot intenta encontrarle sentido a todos esos enlaces RSS, alimentadores y contenido real multiplicándose debajo de su nariz a velocidad exponencial.

"Recomendamos tener bajo estricta observación al MSNBOT ya que, hasta donde sabemos en julio de 2004, no lleva un registro de cuantas peticiones simultáneas le realiza a un servidor. Esto puede resultar en una actividad que se asemeja a un ataque por servicio denegado."

(Fuente: Spidertrack - Sept. 20 2004)

y

"Aquí hay una lista incompleta del tipo de cosas que MSNBot hace rutinariamente en este sitio:

* busca repetidamente grandes archivos binarios, incluyendo imágenes ISO de 500 megabyte, que están adecuadamente servidas como archivos binarios y no han cambiado durante cierto tiempo; 21 acciones de extracción para 4 archivos lo cual se tradujo en 3.7 gigabytes de transferencias esta semana. (Ver MSNbotBinariesProblem)

* busca agresivamente alimentadores de sindicación, muchos de ellos sin cambios; 1,615 búsquedas de 329 alimentadores llegando hasta 45 megabytes de transferencias esta semana. La mitad de los 10 alimentadores más requeridos no han cambiado desde la última semana, sin embargo fueron requeridos 12 veces o más. (Ver MSNbotCrazyRSSBehavior)

* nunca utiliza el condicional GET, incluso cuando está buscando agresivamente alimentadores de sindicación. (Ver AtomReadersAndCondGet)

* vuelve a examinar agresivamente contenido que no ha cambiado y páginas de error, al tiempo que ignora contenido modificado a pesar de que esto es mejor que lo que solía. (Ver CrazyMSNCrawler)

Todos estos comportamientos son indeseables. Muchos de ellos son agresivamente antisociales..."

(Fuente: Banning MSNBot: an open letter to MSN Search - Chris Siebenmann - Nov. 14 2005)

Si usted hace algo de investigación en Google, verá que esta historia no es nueva, con algunas personas informando que el MSNbot se comporta de manera similar a un ataque DDOS acaecido en 2004. Abundan comentarios más recientes de webmasters y editores que habían tenido el mismo problema (si usted es bueno para encontrarlos) y continúan hasta el día de hoy.

Entonces ¿cuál es la solución para el MSNbot?

Utilizar y administrar su archivo robots.txt de manera inteligente. Este archivo de texto, el cual está ubicado en sus servidor, le informa a las arañas de los motores de búsqueda como el MSNbot, cuáles son las reglas a la que tienen que atenerse para examinar su sitio. De hecho, usted puede prohibir arañas específicas, limitar su acceso y controlar que grupo de páginas en particular quiere que indexen.

Puede aprender a usar más efectivamente el archivo Robots.txt en Wikipedia (en ingles).



Canal Oficial

Microsoft sugiere informarles oficialmente del tema en:
http://g.msn.com/0HEMSN_SEARCH...



Lea lo que han descubierto otras personas:

Bots, Spiders and Bandwidth
Enero 5, 2006

Banning MSNBot: an open letter to MSN Search
Noviembre 14, 2005

Si te gustó la nota puedes recibir actualizaciones suscribiéndote via RSS o via email.

O compartirla:
 
 
 
 
Comentar    
blog comments powered by Disqus
 


 

 

 

 

Creative Commons License
This work is licensed under a Creative Commons License.

 

5761


Curated by

Publisher MasterNewMedia.org - New media explorer - Communication designer
Web Analytics