Si se ha contratado un paquete económico con volumen de tráfico limitado, entonces uno comienza a preocuparse cuando el tráfico en la web se incrementa considerablemente.

Este tráfico no solamente es generado por los visitantes de la web, sino también por los bots o robots de los diferentes motores de búsqueda y otros servicios que escanean la web.

Por ese motivo, y pensando en los webmasters Google hace poco mas de un año ha centralizado todos sus servicios de bots, como ser el googlebot, bot de imágenes, AdSense, news, etc. y ha creado en un cache centralizado de paginas web que puede ser usado por todos sus servicios. Solamente, en caso de que la página en el cache ya sea antigua o todavía no haya sido registrada salen los bots del servicio especifico a visitar la página requerida. De esta manera Google ha contribuido a disminuir el volumen de transferencia generado por los bots.

Pero a pesar de esto, muchas veces es necesario disminuir el volumen de transferencia de la web.

Ahora te presento una serie de procedimientos que te pueden ayudar:

1. Análisis
La meta principal para disminuir el volumen de transferencia es la reducción del tamaño de las páginas de la web. Aquí se debe considerar tanto el código HTML así como imágenes y otros componentes de multimedia.

Seleccionar las páginas que más trafico generan
No es necesario disminuir el tamaño de todas las páginas de una web, sino más bien solamente de las páginas que generan más trafico. Generalmente estas páginas hacen un 80% a 90% del tráfico total.

Para encontrar estas páginas, solamente se debe analizar los logs del servidor web u otras herramientas como Google Analytics.

Analizar los componentes de la página
Después de haber detectado y seleccionado las páginas con más tráfico, se debe analizar su tamaño, y el tipo de componentes que contienen.

Para esto, existen en Internet muchas herramientas que te pueden ayudar, como por ejemplo Web Optimization.

Esta herramienta muestra todos los tipos de objetos de la página, así como también sus tamaños, y los tiempos de descargas para diferentes velocidades de acceso, como se puede apreciar en la siguiente imagen:

2. Optimización del tamaño de la página
Con el reporte anteriormente mencionado se puede comenzar a optimizar el tamaño de las páginas seleccionadas.

Imágenes
Una de las grandes sorpresas de este reporte, es que las imágenes hacen el grueso del tamaño de las páginas. Aquí, nuevamente, uno debe concentrar la atención solamente en las imágenes más pesadas.

Estas deben ser optimizadas con herramientas gráficas y/o modificando sus formatos. También se debe analizar la posibilidad de suprimir imagenes o por ejemplo remplazarlas con objetos css o atributos de color en HTML .

Código HTML
A pesar de que el código HTML generalmente es mucho más pequeño que las imágenes y objetos multimedia, es muy importante generar un archivo de HTML compacto por los siguientes motivos:

• Descarga y rendering rápidos Si el código HTML es pequeño, la página puede ser descargada y visualizada rápidamente por los navegadores. Luego, las imágenes y los otros componentes se van descargando poco a poco. Este efecto causa en el usuario la impresión de que la web es rápida y lo anima a continuar navegando.
• Reduce el volumen de transferencia de los bots Generalmente los robots de los buscadores se interesan solamente por el texto de la página y por eso solo leen el código HTML. Si este código es pequeño, el volumen de transferencia usado por los robots puede disminuir considerablemente. En muchos casos, esto también podría mejorar la frecuencia de las visitas de los bots.

El tamaño del código HTML se puede optimizar de muchas maneras:

Generar código compacto
Se deben evitar en el código los espacios y los cambios de carril (carridge return) , se debe usar nombres cortos para los identificadores de las clases y otros objetos. Por ejemplo, en vez de usar un identificador como ClasseDeCabecera se podría usar la abreviación cdc. El mejor ejemplo para aprender como optimizar el código HTML es leer el código fuente de las páginas de Google.

También se debe evitar en lo posible colocar comentarios en el código. En varios casos, he comprado que quitando los comentarios de una página – por ejemplo mediante un pequeño script que lea el código HTML y quite todos los comentarios antes de enviaro al cliente – se puede ahorrar unos 2 a 3 KBytes por página.

Si se asume por ejemplo, que esa página es descargada 10.000 veces al día, entonces se puede lograr un ahorro de unos 29,29 Megabytes de tráfico por día.

Comprimir el código HTML
Si se usa PHP para generar las páginas web, existe la posibilidad de comprimir el código HTML y enviarlo así al cliente. Los navegadores o browsers de ultima generación reconocen este código comprimido y lo descomprimen para visualizarlo. Por ejemplo, si un archivo HTML tiene unos 50 KB en estado normal, su tamaño comprimido es de unos 7 a 8KBytes que son los que realmente se transmiten desde el servidor web hasta el cliente. Esto significa nuevamente un gran ahorro en el volumen de transferencia de los datos.

El código en PHP que se debe colocar al inicio de cada página es el siguiente:

En caso de que el servidor web tenga la extensión zlib habilitada, el código generado (output) es comprimido antes de ser enviado al cliente.

Un ejemplo claro del resultado que ha causado el uso de compresión en uno de mis proyectos se lo puede observar en la siguiente imagen:

Después de que la compresión del código HTML fue habilitada, el volumen descargado diariamente por los bots de Google se ha reducido considerable, mientras que el número de páginas escaneadas no ha disminuido.

El otro efecto positivo de esta compresión ha sido que la carga del servidor ha disminuido considerablemente a pesar de que el numero de visitas no ha caido. Esto se debe a que que la cantidad de paquetes de datos transmitidos entre el servidor y el cliente ha disminuido también.

3. Conclusiones
Como se puede observar, el incremento del tráfico en una web, no necesariamente debe obligar a contratar un paquete con mas transferencia que siempre resulta ser más caro.

Lo que primero se debe hacer es analizar el origen del problema, y en caso de poder optimizar el tamaño de las páginas se lo debe realizar con todos los métodos explicados anteriormente.

La reducción del tamaño de las páginas tiene también otra ventaja adicional: El usuario percibe una mejor usabilidad lo que puede llevar a mejorar el tiempo de permanencia en la web y también a aumentar el numero de las visitas.

Por lo que he podido apreciar, parece que las votaciones y criticas se realizan muchas veces por usuarios que no tienen ninguna idea sobre el contenido de la misma, y lo hacen solo con el afán de conseguir los votos necesarios (inicialmente se necesitan votos 4) para poder enviar sus propias noticias.

Meneáme
Es la página que sin duda más trafico tiene, pero en la que se hace más difícil enviar una noticia. Siempre aparecen votos negativos de usuarios con muy poca experiencia y sin conocimiento sobre el tema de la nota enviada.

También me parece que existen algunos usuarios que solamente se dedican a censurar las notas para lograr que las propias puedan avanzar en la cola

Debido a que el Karma del votante tiene mucho peso para la publicación o el descarte de la nota, posiblemente existen algunos usuarios que tratan de impedir la publicación de las historias que no les gusta.

Enchilame
Es la versión mexicana de Menéame y parece que trata con más fairness (decentemente) a sus usuarios. De todas maneras las historias siempre necesitan más tiempo en ser publicadas.

Negóciame
Ya que este servicio se ha especializado en el campo económico y financiero, tengo la impresión que sus usuarios tienen más conocimiento al realizar las votaciones o criticas a las notas. La posibilidad de que una historia sea publicada en Negóciame es mayor que en los anteriores servicios.

Resumen
El siguiente diagrama muestra el tráfico de los tres servicios, según Alexa. Aquí se debe mencionar que Negóciame solamente tiene un mes de vida.

Sin duda, solo el envío de una historia genera un aumento inmediato de visitas en la página que contiene la historia, a pesar de que vaya bajando y luego sea descartada, como se puede apreciar en el siguiente diagrama:

También se debe mencionar que este efecto de atracción de trafico es solamente temporal.

Luego de que una historia ha sido publicada, el numero de visitas que provienen de estos servicios cae muy rápidamente. Después de dos días nadie se acuerda de la historia.

Por este motivo se debe planear la pregunta: Vale realmente el esfuerzo de enviar historias a estos sistemas que solo generan un incremento del tráfico temporal?

Actualización: Este tipo de servicios se los conoce como social bookmarking.

Por este motivo, es muy común observar que páginas web de empresas importantes casi no reciben visitas debido a que no están bien posicionadas en los índices de los buscadores.

Hoy en día, tener solamente una web en Internet ya no es suficiente. Se debe trabajar mucho para conseguir visitantes y mantener el proyecto actualizado.

Uno de los pasos más importantes después del diseño y la publicación de proyectos web, es la fase de inscripción en los buscadores y su respectivo posicionamiento.

Como ya es conocido, la mayoría de los visitantes de una página web se origina desde Google. Dependiendo del país y de la popularidad de Google, el porcentaje varía desde 60% a un 85%. Por ese motivo, lo más importante para llevar a buen termino un nuevo proyecto web, es la inscripción del proyecto sobre todo en Google.

Debido a que en los últimos años, los spammers han tratado de ganar las primeras posiciones en los índices de los buscadores, los algoritmos de los motores de búsqueda han tenido que ir adaptándose a esta nueva situación. Por ejemplo, Google ha implementado una serie de criterios para dificultar el posicionamiento de páginas con SPAM en su índice.

Uno de estos criterios es la edad y la calidad del dominio: Si el dominio es nuevo y ha sido registrado por un minino de tiempo, entonces Google sospecha de que se puede tratar de uno de los miles de dominios que crean los spammers cada día.

Otro criterio es el grado de confianza que Google da a cada web. Si se desea posicionar una web para palabras clave competitivas, entonces esta debe cumplir algunos criterios de confiablidad, como por ejemplo recibir enlaces de páginas con autoridad. Caso contrario la página puede ser penalizada y quedarse en las ultimas posiciones del índice. Este fenómeno es conocido por los webmasters como SandBox, aunque este termino es rechazado por Google.

Por estos motivos, la inscripción de un nuevo proyecto web debe ser bien planificado y realizado con mucho cuidado. La primera carta de presentación a Google ayudará o dificultará el posionamiento de la web en el buscador.

La siguiente sección presenta un catalogo de tareas que se deberían realizar para inscribir correctamente una web en Google.

Antes de la inscripción
Es muy importante que antes de la inscripción de la web en Google se termine completamente el proyecto, pues inscribir una página en construcción, con un contenido temporal o en borrador puede dañar la imagen de la página frente a Google.

Se debe evitar que Google comience a escanear la web antes de que este concluida. Esto se puede lograr solamente si no se colocan enlaces desde otras páginas.

Se debe controlar la calidad del contenido y controlar si existe contenido duplicado.

Revisar si todas las URLs en las páginas son accesibles. Para esta tarea se puede por ejemplo usar Xenu, un programa para controlar los enlaces de una web.

Revisar los matatags de las páginas, por lo menos de las principales, o de las que se desea posicionar en especial. Sobre todo se debe tener en cuenta los metatags keywords y description, que son usados por Google y otros buscadores para generar la descripción de la página que aparecen en los resultados del buscador.

Crear un archivo robots.txt describiendo exactamente qué páginas no deben ser escaneadas por los robots de los buscadores. Si es que se omite este paso, puede suceder que en el índice aparecerán páginas solamente para uso interno o informaciones que no se desean presentar en Internet. Informaciones para generar el archivo robots.txt se pueden encontrar aquí.

Se debe controlar si la página web se puede alcanzar desde www.mi-dominio.com o mi-dominio.com y evitar las URLs canónicas.

Inscripción
Para poder ser indexado con facilidad y rápidamente en Google se deberían seguir los siguiente pasos:

• Registrar la web en Google Webmaster Central la página de herramientas para Webmasters de Google.
• Crear un Sitemap de la página usando alguna de las herramientas que se mencionan aquí, subirlo al servidor web e incribirlo en Google Sitemaps.
• Finalmente, se debería inscribir en Google usando los buscadores de Google en algunos idiomas: Ingles,, Español. Aunque no esta comprobada la efectividad de este método de inscripción, no se la debe obviar.

Creación de enlaces
Uno de los pasos más importantes para acelerar la inscripción y la indexación de la nueva web en Google es colocar algunos enlaces hacia la nueva web desde páginas que tengan un buen PR (por lo menos PR4) y que sean escaneadas por los robots de Google con bastante frecuencia.

Control
Generalmente, si se siguen todos los pasos mencionados anteriormente, la web debería aparecer en el índice unos 2 o 3 días después de su inscripción.

Inicialmente el índice muestra solo la página principal y luego, poco a poco y según la estructura de los enlaces internos, aparecen las páginas internas. La forma más sencilla de comprobar si la web ya ha sido indexada, es usar el comando site:mi-dominio.com

En caso de que después de una semana, la web todavía no aparezca en el índice de Google, se debería conseguir mejores enlaces para acelerar el proceso de indexación.

Mantenimiento y actualización
Luego de que se haya logrado la indexación en Google es muy importante mantener interesados a los robots en escanear la página con frecuencia. Esto solo se consigue generando continuamente nuevos contenidos que no sean duplicados, y creando enlaces entrantes de webs con el mismo tema.

Conclusión
Si es que se siguen todos los pasos mencionados en este artículo, el nacimiento de una nueva web en Internet, su presentación a Google, y su posterior indexación deberían funcionar sin ningún problema. Adicionalmente, esta carta de presentación en Google ayudará mucho para que el buscador dé un voto de confiabilidad ayudando así su posicionamiento en el índice, lo que significa la generación de trafico.

Después de leer todos los comentarios puedo resumir lo siguiente:

Dependencia del tipo de negocio
E-Comercio (B2B) : Negocios entre mayoristas generalmente no dependen de las visitas generadas por los buscadores. Aquí se trata de un grupo selecto y pequeño de usuarios que se consigue mediante ferias, anuncios en revistas y periódicos especializados; y que generalmente son recurrentes.
Actualización: Artículo que comenta que el mercado de los buscadores si funciona también en B2B.

Ventas/Servicios al publico (B2C): En este tipo de negocios es muy importante la generación de visitas mediante los buscadores. Solamente si la empresa ya esta bien establecida como por ejemplo Amazon.com, se puede prescindir de las visitas generadas por los buscadores.

Pero aquí también se debe diferenciar entre el tipo de negocio que se realiza:

Productos y/o servicios tangibles: En este tipo de negocios se tienen generalmente inversiones, posiblemente un inventario, tal vez algunos empleados, una oficina alquilada, etc. En caso de que los clientes desaparezcan debido a la caída del sitio en el ranking del buscador, esto puede causar la quiebra del negocio. Por este motivo, solamente apuntar a un buen posicionamiento en los buscadores es muy riesgoso.

Servicios intangibles: Aquí se tienen servicios de afiliados, franquicias, o anuncios para todo tipo de partners. En este tipo de negocios, las inversiones son mínimas. Los costos del servidor, tal vez de un webmaster, y otros no son muy altos. En caso de que los ingresos caigan debido a la falta de visitas por causa de las bajadas del ranking en los buscadores, se puede por lo menos algunos meses, continuar el proyecto sin tener que sufrir grandes perdidas económicas.

Recomendaciones generales

Diversificación
Si es que uno desea vivir solamente de los negocios en Internet, debe tratar de diversificarse generando varios proyectos en diferentes nichos para que en el momento de que las visitas y/o clientes de un proyecto desaparezcan por las caídas en el ranking de los buscadores, por lo menos temporalmente los otros proyectos puedan compensar estas perdidas.

Minimizar los costos
Debido al gran riesgo que existe en los negocios en Intenet, no se deben realizar inversiones mediante prestamos, o por ejemplo sacarse un coche con el primer cheque que llegue. Se deben controlar cuidadosamente los costos mensuales y tratar de que el ROI sea siempre lo más alto posible. Solamente cuando se tenga certeza de que se puede ampliar el negocio en forma segura, se pueden realizar las inversiones necesarias.

Generar reservas
Debido a la volatilidad del ranking en los buscadores, siempre es necesario tener ahorros, para que en caso de que por algunos meses las visitas y/o clientes desaparezcan, se pueda sobrevivir sin la necesidad de abandonar el negocio y tener que dedicarse a otra ocupación.

Finalmente aquí otro artículo interesante en CNN Money: How Google can make – or break – your company

A pesar de que posiblemente esta nueva infraestructura todavía esta en la fase de estabilización, parece que Google ya esta comenzando a realizar algunos experimentos para analizar sus resultados y en caso de ser satisfactorios podrían ser introducidos en el algoritmo ‘oficial’ del buscador

Esta idea se origina en la observación de los diferentes data centers (DCs) de Google en las ultimas semanas. En la era pre Bigdaddy, los ingenieros de Google realizaban sus pruebas solamente en algunos DCs y luego, después haber logrado sus objetivos, propagaban esos datos a los restantes DCs.

En las ultimas semanas se ha podido apreciar algo diferente: Se han observado diferentes series o clases de índices repartidos por todos los DCs. Por este motivo las posiciones de las páginas web han estado variando mucho, hasta el punto de que los foreros en WMW, expertos en el análisis de los DCs, han quedado totalmente desconcertados, ya que no han encontrado ningún concepto o teoría clara sobre el comportamiento de los DCs.

Análisis
Ahora bien, cómo se puede analizar correctamente el ranking o posición de una página web, suponiendo que Google esta usando diferentes índices en sus data centers, como resultado de la aplicación de diversos grupos o clases de algoritmos?

Después de haber observado la posición de muchas páginas web de varios proyectos, o mejor dicho dominios, en los diversos data centers de Google durante estos últimos meses, he llegado a las siguientes conclusiones:

Páginas web que pertenecen a dominios bien establecidos en Google y que poseen algún tipo de autoridad, han mantenido su ranking o posición en casi todos o todos los data centers.

Mientras que páginas que por uno u otro motivo todavía son débiles, o que estaban afectadas por alguno de los filtros de Google (poca antigüedad, contenidos duplicados, efecto sandbox, etc.) han estado variando continuamente de ranking en los data centers.

Eso significa entonces que páginas fuertes son estables a las posibles variaciones de los diferentes algoritmos de Google, mientras que las páginas débiles, son muy susceptibles a las variaciones de los algoritmos aplicados en los data centers.

Esta observación me lleva a definir un nuevo concepto: Estabilidad del Ranking de Google, o en ingles Google Ranking Stability (GRS).

El GRS es entonces una métrica que define la fortaleza o estabilidad de una página web en relación a los diferentes algoritmos que se pueden aplicar para generar un índice.

Si podemos calcular el GRS de una página, entonces sabemos cuan resistente es a los cambios algoritmicos que Google pueda introducir.

La siguiente tarea es entonces, encontrar un método para poder calcular el GRS de una página. Para esto necesario desarrollar una nomenclatura formal y una metodología de cálculo.

Nomenclatura
Para poder crear una herramienta formal que pueda calcular el GRS es necesario realizar algunas definiciones:

- d₁,…,d_n sean los data centers de Google
- u sea la url de una página web
- kw sean las palabras claves con las que se realiza una búsqueda.

Entonces,

p_i[u|kw] es la posición de la página u para las palabras claves kw en el data center i.

- num sea el numero máximo de posiciones que el buscador de Google nos permite observar. Este valor actualmente es 100.

Con esto podemos fácilmente definir la posición promedio de una página u para las palabras claves kw en los n data centers de Google de la siguiente manera:

El Google Ranking Stability (GRS) de la página u para las palabras claves kw lo definimos de la siguiente manera:

Sea

Entonces tenemos

La anterior formula la podemos explicar de la siguiente manera:

El término MAX{p₁[u|kw],…, p_n[u|kw]}\{ p_i[u|kw]>num}

es el máximo de todas las posiciones p_i[u|kw] de la página u para la búsqueda kw, pero sin tener en cuenta las posiciones mayores a num.

Mientras que el término MIN{p₁[u|kw],…, p_n[u|kw]}\{ p_i[u|kw]>num}

es el mínimo de todas las posiciones p_i[u|kw] de la página u para la búsqueda kw, pero sin tener en cuenta las posiciones mayores a num.

En palabras sencillas, esta parte de la formula nos da el ruido de las posiciones de la página u para la búsqueda kw en cada uno de los data centers. Pero como estamos definiendo la estabilidad, restamos de num este valor, y obtenemos:

Cuanto más grande es el valor de GRS, entonces mas estable es la página u para la búsqueda kw.

La herramienta
Para poder comprobar los resultados del Google Ranking Stability (GRS) he desarrollado una pequeña herramienta que ahora es de uso publico y se encuentra aquí.

Para finalizar este artículo deseo presentar algunos casos con la mencionada herramienta.

Caso 1: Página con poca estabilidad

La siguiente página tiene una gran variación en las posiciones (desde la 4. a la 42.) para la búsqueda kw en los diferentes DCs. Por eso, solo tiene un GRS de 62%

Caso 2: Página con una estabilidad media

La diferencia de las posiciones de esta página para kw en todos los DCs es relativamente pequeña (entre 9 y 16). Por este motivo su GRS ya es del 93%, mucho mas alto que en el primer caso.

Caso 3: Página totalmente estable
En este ultimo caso, la posición de la página para la búsqueda kw es en todos los DCs la misma (posición 5). Esto significa que esta página es resistente a las variaciones de los algoritmos en los diferentes DCs.

Comentarios y opiniones sobre el tema son bienvenidos!

Este valor es uno de los parámetros para el cálculo del PageRank que hasta hace un tiempo era una muestra clara de la popularidad de una página. Páginas que tenían PRs altos, siempre aparecían en las primeras posiciones del buscador.

Pero en los últimos meses, se ha hecho cada vez más evidente que el tener un PR elevado ya no es garantía para aparecer en las primeras posiciones del buscador. Frecuentemente se observa que páginas con PR bajo están en las primeras posiciones para búsquedas de palabras claves competitivas, mientras que páginas con mayor PR aparecen atrás.

Estas observaciones son una señal clara de que Google ya no esta tomando los enlaces entrantes a una página como uno de los factores mas importantes para el cálculo de popularidad de una página.

Una de las teorías que se esta manejando es que ahora Google estaría usando otros parámetros adicionales para el calculo de popularidad, como se puede apreciar en una discusión en WMW.

2. Nuevas métricas
Es muy cierto que los datos que se pueden obtener acerca de las visitas de una web, pueden ser usados para analizar la popularidad y la calidad de contenido de una web. Por ejemplo con las siguientes métricas se pueden obtener una serie de parámetros para valorar una web:

Trafico total de una página
Cuanto más visitantes tenga una página, muestra más que es interesante para sus visitantes

Tiempo de permanencia
Cuanto un visitante más tiempo permanezca en una página, es un indicio de que la página tiene buenos contenidos y que son interesantes para sus visitantes.

Visitas recurrentes
Cuando los internautas regresan varias veces o periódicamente a un página, es un indicio de que el contenido es interesante y de interés para sus visitantes.

3. Como obtener esa información?
Para el cálculo del numero y calidad de los enlaces entrantes de una página ya existen algoritmos bien conocidos y solamente se necesita un robot que visite todas las páginas de Internet y una gran capacidad computacional para el procesamiento de los datos.

Pero como puede un buscador obtener información sobre el trafico de una web? Es bien conocido como Alexa extrae información para obtener datos sobre el trafico de los sitios: Usando los datos que le proporciona su barra de herramientas (toolbar). Pero también es muy bien conocido que los resultados que presenta Alexa son relativos y tienen un gran margén de error. Pues, solamente grupos especiales de usuarios usan el toolbar de Alexa, mientras que la gran masa de los internautas no puede ser registrado.

En lo que se refiere a Google, se sabe que tiene más posibilidades de obtener estos datos. Entre las posibles fuentes se cuentan:

El buscador: Es conocido que Google hace tracks de los clics que aparecen en los resultados del buscador.

Google Toolbar: La barra de herramientas, en forma similar a la de Alexa, puede proporcionar a Google una gran cantidad de información sobre el comportamiento de los usuarios y sobre las páginas que visita.

AdSense: Google puede obtener información muy exacta acerca del comportamiento de los visitantes que entran a páginas con AdSense, usando su código en JavaScript y los coockies que coloca en las maquinas de sus visitantes.

Analytics, la página personalizada, etc.: Como ya es conocido, Google ofrece una serie de servicios de los cuales puede obtener información para analizar el trafico de las páginas web.

4. Conclusión
Como se puede observar, Google tiene diferentes las posibilidades de obtener información sobre el trafico de una página web. Por otro lado, se sabe que Google es especialista en manejar inmensas cantidades de datos y realizar data mining.

A pesar de todo esto, no creo que Google pueda obtener la información completa de todas las páginas de Internet para poder usarlos como parámetros fundamentales del calculo del ranking en su buscador.

Posiblemente, va ha formar parte, o tal vez ya lo es, de los muchos factores que usan para calcular el ranking.

Todo esto solamente va dificultar más aún el trabajo de los SEOs y spammers para posicionar sus páginas, ya que con el aumento de la complexidad de los algoritmos del buscador, se hace más difícil analizar correctamente, por qué una página aparece en esa posición de los resultados del buscador.

Debido al aumento del numero de transacciones, recién salió a luz que alguna componente del proyecto no estaba funcionando bien.

Pero como saber que era lo que estaba sucediendo en el servidor?

2. Monitoreo
Una forma de investigar lo que estaba sucediendo en el servidor era colocar mensajes de Debug, pero en un sistema que esta en producción, o como ahora se acostumbra a decir live, no era posible.

La única forma era entonces monitorear directamente la base de datos de MySQL para encontrar el origen del problema.

Buscando un poco en la red, encontré en el blog de Ajaxian la herramienta que estaba necesitando. Un monitor de MySQL en Ajax (AjaxMyTop) que muestra periódicamente el estado actual de todas las conexiones a una base de datos. Es una herramienta muy sencilla que recién se esta comenzando a desarrollar (versión 0.1) pero que tiene un gran futuro.

1. Cuando los usuarios accesaban a algunas páginas (justamente aquellas que están en las primeras posiciones de Google), no todas las conexiones a la base de datos se cerraban al terminar el proceso del web server.De esta manera, en muy corto tiempo, el número de conexiones abiertas crecía rápidamente antes de que los timeouts del servidor pudiesen actuar. En las horas pico, el servidor tenia unas 4000 pageviews por hora, es decir unos 66 pageviews por segundo.
2. Cuando las páginas del proyecto, que estaban ahora en las primeras posiciones de Google eran accesadas, se podía observar en el monitor que el número de conexiones a la base de datos aumentaba desmesuradamente. En las horas pico, esto causaba que mi proyecto consumiera una gran parte de los recursos del servidor de la base de datos.

4. Solución
En el caso 1. el problema estaba claro: En algún lugar del código yo no había cerrado la conexión a la base de datos. Este error fue resuelto rápidamente.

El caso 2. era más difícil de resolver. Aquí no me quedo mas que realizar pruebas en mi sistema local, colocando mensajes de Debug en una de las páginas que era mas accesada por los usuarios.

Después de un análisis profundo de todos los accesos a la base de datos, me di cuenta que la programación con objetos y a alto nivel puede ser en algunos casos muy peligrosa: En muchos lugares del código de PHP usaba funciones de una clase, que al parecer sencillas de usar, realizaban cada vez conexiones a la base de datos. De esta manera cada acceso a esta página web generaba 33 conexiones a la base de datos. Esto significaba unas 2178 conexiones a la DB por segundo en las horas pico.

La solución a este problema fue obtener los datos que se necesitan de la DB al inicio y colocarlos en una variable global para que puedan ser usada posteriormente por la clase anteriormente mencionada. De esta manera se pudo reducir el número de las conexiones a la DB en mas de un 60%.

5. Recomendaciones
Como conclusión de esta experiencia, que fue causada por haber logrado una de mis metas: Aumentar el trafico en uno de mis proyectos, puedo dar las siguientes recomendaciones para webs de alto trafico:

1. Las conexiones a la base de datos deben ser lo mas cortas posible. Se debe evitar llamar a otras funciones que no sean accesos a la base de datos durante una conexión:

- Abrir conexion a la DB ( mysql_connect() , mysql_select_db())
- Ejecutar query ( mysql_query() )
- Cerrar conexión de inmediato (mysql_close() )

2. En caso de que se necesiten datos de un registro o varios registros de la DB en diferentes partes de la página, se debe crear una variable global, obtener los datos desde la DB al inicio y luego usar solamente la variable global.

3. Durante el desarrollo de las páginas web se debe revisar continuamente los recursos que se usan al llamar las diferentes funciones.

4. Hacer pruebas de carga generando un trafico artificial. Esto se puede realizar con un pequeño script en PHP que escanee con alta frequencia la página a testear. Parlamente se puede analizar con un monitor el rendimiento de la base de datos y del mismo web server.

Artículos relacionados
- Monitorear MySQL
- Rendimiento en MySQL

Hace unos meses preparé artículo sobre el efecto Sandbox explicando su origen y sus efectos.

Lamentablemente no existe una forma o método fiable para poder comprobar si una web ha entrado al Sandbox. En los últimos meses han estado cursando por la red muchas teorías sobre cómo chequear, si una web esta en el Sandbox.

Hoy día, he encontrado una nota en el blog de SEOmoz en la cual randfish describe una checklist para comprobar si una web se encuentra en el Sandbox.

Esta lista me parece bastante bien elaborada ya que tiene diferentes formas de hacer los tests y describe con claridad los pasos a seguir y sobre todo, las conclusiones que se pueden sacar de los resultados obtenidos.

Uno de los tests es el uso del buscador AskJeeves que lamentablemente para búsquedas en español todavía no tiene muchas páginas indexadas.

En principio existen dos tipos de herramientas:

1. Programas para el Desktop
Son programas que corren en la computadora. Se conectan mediante Internet a los buscadores y escanean sus páginas WEB para buscar las palabras claves. Estos programas también pueden usar las API’s de los buscadores como la API de Google.

Un programa gratuito es el Google Monitor que usa la API y también escanea el buscador de Google.

La ventaja del Google Monitor es que todos los datos se los mantiene en forma local, y se los puede usar con otros programas.

El problema de esta herramienta es que como escanea a Google, mucho y muy rápido, después de un tiempo Google bloquea la dirección IP, pensando que se trata de troyanos en una computadora infectada, que estan haciendo consultas a Google para propagarse.

2. Herramientas en la Web
Son sitios que permiten buscar las posiciones directamente desde los servidores WEB usando los métodos mencionados anteriormente (escaneo y API’s).

DigitalPoint es la herramienta más conocida. La ventaja es que mantiene un historial de todas las consultas realizadas en el servidor WEB.

La mayor desventaja es que como usa la API de Google, los resultados no son exactamente los mismos que tienen los data centers que usan los usuarios normales.

Otras herramientas de este tipo son Google Ranking que usa la API de Google, pero también permite monitorear las posiciones de las webs en Yahoo y MSN.

Otra herramienta interesante de este tipo es LinkVendor’s SERP Position que también muestra las posiciones en Google, Yahoo y MSN.

Para poder comprender realmente el problema, primero es necesario entender exactamente el termino.

Definición
Una URL (Uniform Resource Locator) canónica es una denominación unívoca que describe un nodo en la estructura jerárquica de los DNS (Domain Name Server) en Internet.

En otras palabras: es el nombre propio de cada una de las páginas webs en Internet. La construcción de las URL’s se realiza de acuerdo a la nomenclatura definida y jerarquizada

{protocolo}://{directorio o archivo}:{numero de puerto TCP}.

Por ejemplo, si la página web se llama ejemplo.html y está en el dominio mi-dominio.com entonces la URL canónica será:

http://mi-dominio.com/ejemplo.html

Pero en el mundo del Internet, se hizo costumbre colocar delante del nombre del archivo www para remarcar de que se tratá de una página WEB (www= World Wide Web), lo cual ahora ya se ha hecho un quasi estandard. Por este motivo, la mayoría de los servidores Web permiten seleccionar una página mediante las dos denominaciones.

En nuestro ejemplo:
http://mi-dominio.com/ejemplo.html
y
http://www.mi-dominio.com/ejemplo.html
mostrarían la misma página.

Google y las URL’s canonicas
Debido a que Google escanea todo lo que encuentra en su camino, en caso de que por algún motivo la web tenga algun enlace de la forma http://mi-dominio.com, es decir sin www, también va ha tratar de indexarla como la web clasica http://www.mi-dominio.com.

Ahora bien, como Google últimamente ha cambiado sus algoritmos para detectar contenido duplicado, entonces Google al tener dos copias de cada página de la web, tiene que decidirse por una de las ellas. La primera mantiene su ranking y la otra es castigada y relegada a las ultimas posiciones.

Como detectar si mi web sufre de este problema?
Una forma de detectar si Google ha indexado las dos variantes de las URL’s es haciendo la siguiente consulta:

site:www.mi-dominio.com –www

En caso de que no aparezca ningún resultado, entonces Google no ha indexado a http://mi-dominio.com

El test inverso seria

site:http://mi-dominio.com

Esta búsqueda muestra todas las páginas que han sido indexadas sin www.

Como se puede solucionar el problema?
Actualmente Google esta tratando de resolver este problema con sus actualizaciones, pero lamentablemente hasta ahora sin mucho éxito.

Este problema se puede solucionar desde el servidor web, redireccionando la URL http://mi-dominio.com a la dirección clásica.

Para esto, el servidor debe permitir el uso de rewrite_mode. En el archivo .htaccess, que se encuentra en la raíz, se agregan las siguientes lineas:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.mi-dominio\.com$
RewriteRule ^(.*)$ http://www. mi-dominio.com/$1 [L,R=301]