Morir de Fama

Tengo meses repitiendo lo mismo: Podemos morir de Fama. Sucede con los artistas, con los negocios y también pasa a los sitios de alto tráfico.
Desde trabajo con “sitios de alto tráfico” y no es por casualidad. Las duras experiencias que he tenido desde 1999, me ha llevado a través de proyectos donde el mínimo común denominador es el tráfico.

Lo que sucede es que en muchas ocasiones no estamos preparados para trabajar con el tráfico. No tenemos la infraestructura o quizás la experiencia para lidiar con los pormenores de ser muy visitados.

El caso de enel.net

En el 2006, estuve trabajando con varios ejecutivos para lograr “resucitar a enel.net”. A la verdad mis predicciones fueron acertadas: “El dominio dormido” obtuvo unas 16,000 visitas únicas (no hits) en su arranque, que inició en enero 2006.

Ya para abril 2006, no habían recursos para pagar los servidores -no existía el cloud computing, tampoco las acciones comerciales dieron frutos. Aunque la comunidad estuvo muy activa. Entonces se produjo un apagón desde mayo 2006 hasta septiembre 2006, donde tomé control del producto hasta junio del 2008.

A la verdad el apagón mayo-septiembre 2006, impacto al sito con una reducción del tráfico en un 45%, es decir, que perdió su momento. Ese es un caso que siempre recuerdo.

Juegos Panamericanos

Ese es un caso especial. Teníamos una infraestructura contratada en CODETEL, partner de los XIV Juegos Panamericanos Santo Domingo 2003. Nos dieron 3 servidores locales (en su datacenter), los cuales -según la costumbre de la época, utilizamos uno para cada función: Adserving, Contenidos y Foros.

Llegó el día de los juegos, con nuestro sitio que había salido en la prensa y había sido “alabado” por la comunidad local. Pero no contábamos con el millón de visitantes que iba a visitarnos desde los lugares más remotos del continente.

Esos fueron los días más duros de mi vida; quienes no entendían lo que pasaba, solo se paraban a la puerta de la oficina para presionarnos. Recuerdo que Mite siempre llamaba a la calma, pero no había espacio para ello.

Había una realidad: El mega (sí un mega) que nos brindó CODETEL era un cuello de botella y los servidores empezaron a reventar… Solución de CODETEL: Salirse de su propia infraestructura y darnos unos “señores servidores” fuera del país. Tuvimos que hacer un round-robin y un load balancing para poder equilibrar la demanda.

Gracias a Dios siempre utilizamos la buena práctica de servir los contenidos estáticos (como había aprendido con el equipo de Lycos y Yahoo!, hace algunos años atrás). ¿Qué pasó luego? Que como era un pico, la demanda fue bajando, pero al estar 3 días intermitentes, el tráfico buscó otras fuentes y se fue olvidando del “sitio oficial”.

¿Por qué las caídas son tan peligrosas?

Porque desalientan al usuario. Recuerdo a un viejo mercadotécnico que siempre me decía: Cuando abras un servicio, éste no puede dejarse caer. El no sabía nada de Internet para 1997, pero si estaba claro en una regla primordial de Marketing.

Es un asunto serio. Uno puede decir: “Soy tan famoso que se me cae el sitio”. Error, en ese caso, el diseño de tu infraestructura no es escalable. Ojo, (PHP no es escalable) muchas de las aplicaciones en PHP, no son escalables.

Por esta razón es que hay días que intento visitar sitios dominicanos y están fuera por un error 503. Espero que la densidad del tráfico no les provoque un “morir de fama” y puedan estar siempre disponibles para su audiencia y sus clientes.

22 pensamientos en “Morir de Fama

  1. OK. Ahora si.El asunto con eso de las aplicaciones especificamente con joomlas y afines muchas veces depende de la implementacion. Ciertamente que joomla consume demasiados recursos. Una pantalla por default, recien instalado hace unas 30 consultas a la database, en el mejor de los casos. A mi particularmente no me hace gracia. Pero muchos sitios de mediano trafico pueden usarlo muy bien si se aprovecharan las caracteristicas que trae, pero ya eso es otro tema.El asunto con esto es saber escoger las apliciones a utilizar, darles el uso adecuado y nunca (pero nunca) poner todos los huevos en una sola canasta.Y sobre todo dejar la logica de "si le funciona a yahoo me funciona a mi", "si le funciona a new york times me funciona a mi", pues no todos tenemos las mismas necesidades ni infraestructura parecida.Me altere un poco cuando me le faltaste el respeto al lenguaje que me da el moro.Un saludo, Melvyn

  2. Hola Melvin.Creo que utilicé una mala expresión. Debí decir: "Muchas de las aplicaciones en PHP, no son escalables". Porque se diseñan según el momento y luego se preocupan por la escalabilidad, cuando les llega la "fama".Ahora, los lenguajes orientado a objetos tienen la capacidad de emplear diseños que ayuden a la escalabilidad, pero reitero, es necesario diseñar primero para alcanzar ese objetivo.Las prácticas en PHP, son fáciles pero los códigos tienden a no ser eficientes. En .net, peor.En lenguages que son poco usados como JAVA, RUBY y PYTHON, encuentras mejores prácticas al ser un grupo más reducido -y más sofisticado, quienes las aplican.En este caso, es bueno aprovechar las mejores prácticas en cada lado, pero sabiendo donde termina una y la otra.

  3. Respondiendo a Juan Medina: Nos hemos olvidado del primer punto, el Bolsillo ($$$). Muchos sitios mueren por las finanzas primeramente al no poder capitalizar.Otros tienen muchas veces menos tráfico y ganan más dinero. Pero eso es difícil medir, ya que ninguno trabaja por impresiones o costo por mil (CPM). Pero ese es otro caso.En el referente a la infraestructura, el bolsillo obliga a contratar un Dreamhost o un Godaddy, pero muchos no plantean su crecimiento futuro. Es decir, contratan el límite según sus posibilidades. Cuando la fama les llega, muchas veces el capitalizar la misma es difícil, porque solamente es costo al inicio.

  4. Arturo, se que llegué tarde a esta discusion (aunque lo lei desde que salio), pero te tengo la misma pregunta que JuniHH:¿Que es un lenguaje de programacion escalable? Enumerame 3 lenguajes que si sean escalables y 3 que no (aparte de php).Mi opinion es que eso no depende del lenguaje de programacion. Un sistema escalable o no dependerá de su arquitectura, no del lenguaje usado.Pero me gustaria que respondieras lo de arriba y ver como le quitamos el susto a JuniHH

  5. Otras preguntas curiosas:Ya que mencionas alto trafico y de soluciones como WordPress, estamos hablando de sitios hospedados en servidores compartidos (shared hosting), o es que no se tienen los fondos para pagar por los recursos necesarios?Hablamos de infraestructuras o del rendimiento de un lenguaje (aplicacion)(PHP)? Por ejemplo. En ciertas soluciones se usan networks de reparto de contenido, o sea que se necesitan varios servidores para abastecer contenidos basados en posiciones geograficas. Muchas veces no se habla del rendimiento de la aplicacion, si no, donde, como, y cuando corre la aplicacion. Cuando hablamos de grandes aplicaciones (o alto trafico, portales, etc), tenemos por entendido que hablamos de una gran infraestructura. No es que la infraestructura (o el lenguaje) sea o no "escalable", es que no tenemos acceso a dicha infraestructura para desarrollar soluciones. Pero, tambien hay muchas cosas que se pueden hacer para manejar alto trafico en una cuenta de hospedaje compartida.He visto muy pocos blogs Dominicanos con un error 503, si me preguntas a mi, he visto solo a "uno(01)" con esa clase de problemas. Varios blogs populares Dominicanos manejan muy bien "sus" altos trafico. Pero como saber cual es el problema cuando no se tiene acceso completo a una infraestructura? Bandwidth ($$$)? Le echamos la culpa al rendimiento de los componentes que tenemos disponibles en nuestras sencillas cuentas de hospedajes web? O realizamos que necesitamos mucho mas rendimiento y accesso que podemos pagar? Conozco blogs que no solo corren en un solo servidor, y de empresas de hosting que ofrecen este tipo de administracion y soluciones transparentemente. Los fondos hacen las cosas escalables?Ojo, solo trato de añadir interrogantes para continuar la conversacion y tratar de entender los factores en cada situacion. Muy interesante tema Arturo.

  6. Pero recuerda que heredamos mucho Open Source que no aplican buenas prácticas en términos de codificación.Gente de viene de Cobol en las universidades, no rompen el paradigma del LAN, al igual que muchos en .NET. Cuando llevan sus aplicaciones al Web, siempre mueren de fama.Sitios que están basados en Administradores PHP, se ven confrontados con la demanda de recursos, ya que no son herramientas diseñadas para el alto tráfico.Con un WordPress -por ejemplo, no se puede pretender hacer un Yahoo! En ese caso, recomiendo a mis colegas que siempre tengan un plan.En ese punto, ya no estoy dando consultas porque enfrentar los picos de tráfico debe hacerse con seriedad. Un blogger que piensa que es un chiste que su sitio "con tráfico" se caiga, no merece una solución seria.

  7. Interesante articulo. Muy de acuerdo, pero me quede con una incognita:PHP no es escalable? Llevaba años pensando que no es el lenguaje, si no la manera en la que se escribe una aplicacion en PHP la que hace "esa aplicacion" escalable? La inteligencia la añadimos nosotros, no el lenguaje o plataforma. Pensaba que esto se habia aclarado en '04.:)

  8. Sí soy Mercadotécnico; me involucré en Internet desde 1998, cuando hice mi primera Intranet como respuesta a un programa de MIS.Luego en el 1999 dí el paso a e-Marketing y luego en el 2000, trabajé en el primer programa Opt-in (email bajo permiso) del país.El resto es historia.

  9. Justo me inicio con PHP trabajando mi propio CMS cansado de WP. Con ese comentario de tu articulo mas la respuesta que dejaste me has puesto a sopesar errores que estoy cometiendo con mi proyecto al nivel que lo tengo.Realmente gracias por la respuesta, me sirvio de mucho.

  10. Vaya! Casi me tientas a escribir un post nuevo, pero quiero ver Smallville esta noche.Fíjate qué pasa con PHP: Es fácil de aprender, es decir, que alguien con el coefiente intelectual promedio, puede programar algo simple con él.En ese sentido, al ser fácil y que cualquiera puede ser "ducho", da pié a mucho Open Source en el mundo.Ahora, porque sepas codificar en PHP, no implica que sepas hacer una aplicación. Tanto en WordPress, como en Joomla -para citarte dos ejemplos, hay malas prácticas de consultas que castigan a la base de datos.Eso no se nota cuando "dos gatos" visitan tu sitio, sino, cuando entra el "grueso" de visitantes. Cuando empiezas con PHP, el proyecto es barato y fácil, pero cuando llega la audiencia… mejor pregúntale a Twitter y a Facebook.

  11. Un contenido estático es aquél que no depende de una base de datos. Cuando tienes alto tráfico, debes considerar que el tráfico impacta tu servidor HTTP y el servidor de Base de Datos también.En este caso, sucede que muchos sistemas como WordPress, Drupal y Joomla, están en PHP, que es un lenguaje fácil para desarrollar pero no es escalable.

  12. Muy interesante tu post, ademas lo considero un aporte el que comparta esta experiencia. Tengo una pregunta: A que te refieres cuando dices "Gracias a Dios siempre utilizamos la buena práctica de servir los contenidos estáticos"?

  13. Gracias Tuitico, si quieres únete al equipo de trabajo que está realizando el 3er estudio sobre Gobierno Electrónico, ahora realizado por ROCK (anteriormente fue auspiciado por Participación Ciudadana).Así determinaremos otras páginas del estado que están de la misma forma.

  14. Oh, el Cloud Computing!Tu sabes que entre hoy al site de la Direccion General de Pasaportes (http://www.pasaportes.gov.do) y esta "en construccion", desde hace un largo tiempo. Yo pensaba que eso de estar "construyendo" una pagina habia dejado de ser una total falta de respeto. Ni siquiera esta la informacion basica que necesitaba en ese momento. Osea, ni siquiera la direccion, un telefono o un correo electronico para cualquier pregunta!!

  15. Muy interesante tu comentario. Pero la realidad es que muchos confían que con el WordPress tienen sus problemas resueltos.Cuando se caen tienen tráficos. Los demás que no se han caído significa solo dos cosas: 1) No tienen tráfico o 2) No generan picos.Simplemente el modelo de blogging se pone en serio cuando la audiencia crece.

  16. Es una realidad que muchos lugares deben de tener en cuenta al ofrecer sus servicios en la Web.Aunque hay que recordar, q como el mismo caso que tu mencionaste, muchas veces no depende de nuestros servicios, sino de servicios externos que aveces ofrecen y al final no cumplen, pues ellos mismos no estan listo para tales evento.@Shadywww.tecnoplaneta.wordpress.com

Deja un comentario