Viendo entradas en la categoría: Servidores

  • Kentaurus
    Este fin de semana pasé por el experimento interesante de migrar los servidores de un Datacenter a otro.

    Literalmente me refiero, ir al DataCenter, ubicar la cajita que representa el servidor, desconectarlo, subirlo a un camión y llevarlo desde Tampa (donde estaban ubicados los servidores) hacia Atlanta.

    La compañía con la que hospedamos los servidores, Sagonet, para poder continuar su crecimiento decidieron reubicarse en un DataCenter más grande, y eso ocasionó la migración. Y claro, eso implica después volver a conectar todo y rezar porque prenda. Si alguien no sabe de lo que estoy hablando, es una situación tipo Jurassic Park, uno le da "reset" al sistema y cruza los dedos esperando que todo funcione :)

    Y de hecho .. igual que Jurassic Park. No sucedió.

    Mis servidores se los llevaron a las 10pm de la mañana del sábado aproximadamente. Todo desconectado y "en camino".

    Después que venció el plazo, vi mi base de datos regresar a la vida. Excelente, un servidor menos. El problema es que mis servidores web estaban completamente muertos. Um .. deben estar trabajando, pensé, así que simplemente ignoré el asunto y dejé pasar algunas horas.

    ... Para la noche (del domingo) todavía no había nada, así que finalmente escribí un ticket de soporte técnico.
    Nada ....

    Otro
    Nada ....

    Para el lunes en la mañana, decidí entrar en modo de "cliente psicópata" y les escribí "¿alguien podría darme una nota de recibido aunque sea en mi ticket?". El cuál contestaron inmediatamente con un "perdón por la falta de respuesta, estamos trabajando para restaurar el servicio".

    Para el lunes en la noche estuve presionando botones
    ... Servidor de CZ: Prendido
    ... Servidor del wiki: Prendido
    ... Servidor secundario: Prendido
    .... PRO: Prendido

    La vida sería feliz de no ser porque .. en CZ la hora estaba mal, en otro de los servidores mysql no había arrancado, y en otro más la configuración estaba incorrecta. No cabe duda que por eso la administración de servidores es un trabajo completo para algunas personas :)

    Finalmente el día de ayer en la noche tuve todo de vuelta en línea. Y CZ está de nuevo rodando y vivo. No hay actualizaciones, claro, porque ese no fue el punto del ejercicio. Estoy feliz con que siquiera esté funcionando.
    a koneko nyan y Haruhi les gusta esto.
  • Kentaurus
    Tuve la poca agradable oportunidad de usar una computadora con ....
    con ....
    con ....

    Windows XP e Internet Explorer

    Ya se, ya se que pensaran. "yuuuuuuuuuuuuck"

    internet_explorer_meme.jpg

    Fue mi actitud también, tristemente. Y como hago pruebas, lo primero que hice fue abrir cemzoo.

    CemZoo.com -> Bien
    CemZoo.net -> Alertas, alertas everywhere

    everywhere.jpg

    Los errores eran debido a HTTPS

    Internet Explorer (sobre todo el viejito), no está actualizado para tener múltiples certificados en un servidor. Desafortunadamente, cemzoo.com y cemzoo.net utilizan un certificado distinto, porque, después de todo son dominios distintos. El problema es que comparten dirección IP

    Y eso a Internet Explorer no le gusta. Básicamente usa el certificado de cemzoo.com para cemzoo.net, y el resultado es que saca una advertencia gigante que dice

    "CemZoo.net, es peligroso"
    Aléjese
    Aléjese ...

    ... cosas malas
    ... ocurren
    ... cuando entras

    a CemZoo
    a Okita, Kibary <3 y Milenia les gusta esto.
  • Kentaurus
    Desde la semana pasada estoy lidiando con actualizaciones de hardware a nuestro servidor de datos.

    ... Desde hace tal vez un par de meses, por el sistema de monitoreo recibo la alerta de "CZ está caído" .. "CZ está de vuelta", esto ocurre a intervalos durante el día, pero casi sin falta, diario. El hecho de que el sitio se caiga 20 minutos al día no es tan preocupante, pero es molesto, simplemente, debería estar activo todo el tiempo.

    Entrando a revisar el detalle, generalmente es la base de datos que está muy "ocupada", "procesando algo". Y lo que más me preocupaba es que a fechas recientes, lo que veía era una cantidad de memoria considerable utilizada como memoria virtual, generalmente un síntoma de que el servidor está un poco bajo en memoria.

    Curiosamente, el año pasado, que provisionamos CZ para un tráfico incrementado, me conseguí un servidor de base de datos dedicado, la teoría es que un servidor de base de datos dedicado iba a ser mucho más rápido que un servidor compartido con el servidor web y el servidor de aplicaciones. La realidad es que el diseño de una aplicación Mysql + PHP deja mucho que desear para distribuir los componentes y he tenido que lidiar con hardware y configuración todo este tiempo.


    Así que esta semana, decidí finalmente actualizar la memoria del servidor, así que le escribí a mi Account Manager para que me ayudara a coordinar el upgrade memoria del servidor.

    También ha sido .. no 100% transparente.

    Comenzamos el viernes pasado. Y para comenzar, me mandan un correo diciendo "vamos a tirar tu servidor para actualizar la memoria" ... a lo cuál mi impresión fue un "wait, what?"

    No fue un "¿cuando quieres que actualicemos la memoria, avísanos"
    No fue un "¿nos puedes dar una ventana de tiempo de 2 horas para hacer el mantenimiento?"
    Nope, fue un "servidor caído en 3 ... 2... 1.."

    Sigh.

    Bueno, todo sea por mejorar. Dieron de baja el servidor, insertaron el nuevo RAM. El siguiente correo.

    "No teníamos 8Gb de memoria así que le pusimos 6Gb, vamos a pedir que nos envíen la memoria que falta"
    Am .....

    Ok, supongo. 6Gb es mejor que los 2Gb de memoria que tenía el servidor, después de todo. Sin embargo no me hacía mucha gracia el hecho de tener que dar de baja el servicio, una vez más.

    Por si no fuera poco, regreso mi servidor, sin conexión a red (¿yo para que quiero un servidor sin conexión a internet?). Así que estuve enviando correos toooodo el fin de semana hasta que alguien fue al servidor y "reseteo" la red para arreglarlo. "Es que no cambiamos nada de red", me decían. "Es que no tiene conexión", les decía yo de vuelta.

    La única razón por la cuál CemZoo no estuvo caído el fin de semana es porque el enlace de red que se cayó fue el enlace público, y el enlace privado todavía quedaba vivo, así que todo el tráfico estaba ruteado de esa forma.

    El día de hoy en la mañana, recibo otro correo
    "¿Cuándo podemos dar de baja el servidor para instalar los otros 2GB?"

    "Ajá, ahora si preguntan", fue lo primero que pensé.

    Durante las últimas 2 horas el servidor ha estado abajo por una actualización (una vez más) de memoria del servidor.

    Y cuando regresó el servidor.... oh, claro, mi enlace privado de red no estaba funcionando. Sigh.
    Resignado fui y actualicé la configuración para reestablecer las conexiones de red. Y por alguna razón toda la configuración que debió haber arrancado "al inicio" no arrancó, así que tuve que configurarlo de nuevo.

    Siendo estrictos, no hago actualizaciones de hardware más que cada año? cada dos años? Así que tal vez vale la pena el dolor de cabeza y pequeños inconvenientes.

    Así que ahora tengo un servidor de base de datos 4X más poderoso. Eso debe alcanzar para aguantar la carga por lo menos por los siguientes meses. He configurado además el servidor para el 50% de capacidad para dejar un poco de espacio de crecimiento.
    a Degote, koneko nyan y Haruhi les gusta esto.
  • Kentaurus
    PHP 5.5 ha estado afuera durante un rato, pero he estado procrastinando el actualizar el servidor, por la sencilla razón de que PHP no tiene el mejor record de liberaciones "estables", y generalmente encuentran una lista interesantes de bugs post-liberación, así que esperarse a la versión .1 es buena idea.

    PHP 5.5 tiene algunas mejoras interesantes. Además del lenguaje, han incluído la extensión de Zend (Zend Optimizer). Después de hacer benchmarking de desempeño, la extensión se lleva por lejos a sus competidores (APC, XCache), con una diferencia hasta del 30%

    Esto significa que las páginas en lugar de procesarse en 600 milisegundos pueden llegar a procesarse en 400 milisegundos. Aunque en estos momentos el CPU no es el cuello de botella, cualquier optimización es bienvenida.

    Desafortunadamente, no he podido actualizar el servidor de FanficsLandia, por la sencilla razón de que las librerías del sistema operativo no lo soportan, y actualizar el sistema operativo solo para actualizar la versión de PHP no suena razonable.

    Sin embargo CZ ya está corriendo en la última versión de PHP, con páginas un 30% de procesamiento más rápido.
    a Degote, koneko nyan, Velli y 1 persona más le gusta esto.
  • Kentaurus
    boss.jpg


    Estos días he estado trabajando en hacer respaldos tanto de CemZoo como de FanficsLandia

    Mi proceso anterior era bastante manual, básicamente, de cuando en cuando (cada vez que me acordaba - lo cuál resulta ser cada 3 o 6 meses) iba al servidor y daba un tar -c de todo el contenido de CZ

    Y entonces copiaba el respaldo a mi computadora, lo etiquetaba con la fecha y listo.

    Este es un proceso que no hacía muy seguido porque el respaldo de CZ puede llegar a ocupar 50 Gb, y estar descargando 50 Gb seguido no es lo más divertido del mundo, por no decir tardado, por no decir que usa harto ancho de banda, además de ocupar un espacio considerable en mi computadora e inutilizar el disco duro un rato.

    No más.

    Automatizando el proceso

    El primer paso para mi fue tener una conexión decentemente rápida (unos 24Mbs pueden sin problema transferir algunos gigabytes)

    El segundo paso es tener la tecnología correcta. Utilizando una combinación de rsync + ssh, puedo transferir todo el contenido del servidor a mi computadora, de forma parcial. Esto significa que .. si en el día se subieron 400 archivos adjuntos, en lugar de transferir los 50Gb de contenido, puedo transferir selectivamente solo esos 400 archivos adjuntos que se subieron.

    El tercer paso es tener un destino para el respaldo. Para eso compré una confiable Mac Mini, la cuál está conectada el 100% del tiempo, y cada hora está llamando al servidor para ver si alguien ha subido algo nuevo, y descargarlo.

    .... El resultado

    He estado piloteando esto por unos días. El respaldo incremental está funcionando bastante bien, en no más de 5 minutos, cada hora, puedo hacer un respaldo completo del servidor, y mi Mini actúa como un espejo de CZ, con la ventaja agregada de que tengo todo el contenido de forma local para hacer un análisis estático, sin afectar el desempeño del servidor.


    Es un cambio considerable, de respaldar cada 3 meses a respaldar ... cada hora. Pero está funcionando bastante bien, debo decir :) Y es una solución razonable mientras no alcancemos los terabytes de información (nunca, no podría pagarlo)
    a Degote, Velli, Haruhi y 2 más les gusta esto.
  • Kentaurus
    El día de estoy en el taller mecánico (donde tienen Wi-Fi, por supuesto), y ha sido bastante placentero poder entrar sin restricciones a CemZoo y con la consciencia tranquila que la persona de la derecha no es un hax0r observando cada movimiento :) Así que ha pagado. Ha pagado.

    Además, acabo de descubrir una ventaja adicional del hecho de tener https, y es que .. confunde a los firewall corporativos.

    La página CemZoo está generalmente bloqueada en los firewall más agresivos por ser una página de "juegos" (y en algunos otros por ser "contenido adulto" - gracias gente poco útil que pusieron yaoi de Naruto en los grupos, con Sasuke sin ropa). Desde hace unos meses he estado "apelando" la decisión y escribiendo a las compañías que administran a las cyber niñeras para que me saquen de la categoría pero les valgo, o me quieren cobrar, así que lo dejé por la paz.

    Este taller mecánico donde estoy tiene su firewall corporativo de Nissan que bloqueaba todo y no podía abrir CZ, pero hoy ..

    Debido a que el sitio es https, es un sitio nuevo, no lo tienen clasificado, y además es un sitio seguro, por supuesto que no puede ser un sitio random si tiene https, ¿verdad? :) El punto es que me ha abierto sin mayor problema ni preocupación. Hakuna Matata.
    a Lady, Degote y koneko nyan les gusta esto.
  • Kentaurus
    Ayer hice un par de cambios más al soporte para https en el foro. En particular, los cambios fueron los siguientes ...

    1) Después de iniciar sesión en el foro, el foro te "recuerda" y te regresa a https todas las veces siguientes que entres.

    Este era un problema donde, si la persona iniciaba sesión, al entrar de nuevo al foro, en caso de hacerlo por http, la sesión ya no se encontraba iniciada, y lo "forzaba" a iniciar sesión de nuevo (en realidad, podía simplemente haber tecleado https para iniciar sesión automáticamente).

    2) Algunos cambios misceláneos para que el https se comporte mejor en el blog

    3) ahora redirecciona a (antes simplemente cargaba la página).


    Salvo algunos percances menores, creo que la mayoría de las personas no ha tenido problemas en utilizar el foro con el contenido encriptado. El servidor, por su parte, no le parece molestar tener que encriptar todas las sesiones.

    Como algunas personas me mencionaban, algunos navegadores como Chrome ni siquiera muestran el protocolo, solamente la dirección, a lo mucho un candadito mostrando que su información está siendo encriptada, en el mundo ideal, la mayoría de las personas ni siquiera se debieron dar cuenta de que algo estaba sucediendo.
    a Gex, Velli, koneko nyan y 1 persona más le gusta esto.
  • Kentaurus
    Desde hace unos días, he estado trabajando para migrar el foro desde hacia (nótese la s de https). De hecho, si dan clic en la liga, en estos momentos abre sin problema, sin embargo, ese no es el predeterminado porque no todo es alegría. Veamos por qué ...

    1) Contenido mezclado

    Las personas utilizando webkit, chrome o firefox no tienen problema, pero las personas utilizando Internet Explorer 8 (IUC), al entrar al sitio con https probablemente reciban un aviso horrible que dice "peligro, peligro, se ha detectado contenido inseguro"

    La razón de esto es que el sitio tiene tanto http como https, y cuando internet explorer detecta que se ha cargado una imagen no-segura, entonces se queja, con una alarma bastante visible. Chrome es un poco más inteligente, se da cuenta que realmente no pasa nada y simplemente carga la imagen sin dar mucha lata. Pero algunas personas todavía usan Internet Explorer ... así que no me puedo olvidar de ellos ....

    ¿Que hacer?

    Estos días he migrado algunos de los avatares para que carguen en https. No ha sido transparente desde que en la página principal había un caché en el widget de la barra lateral. Esto ocasionó que si una persona abre la página con http (probable), entonces quede guardado.

    .... El plugin de taptalk, no coopera. Fui al sitio de tapatalk a quejarme y prometieron arreglarlo "en la siguiente versión". Quien sabe cuando suceda. Es imposible confiar en la gente de software, la verdad. Por mientras, el plugin de tapatalk no cooperan

    Los logos de administrador, moderador, etc, se cargan de forma no segura. Es necesario moverlos de URL a algún otro lugar con soporte a https ...

    Y algunas otras poquitas imágenes (como el logo del foro), tampoco funcionan de forma transparente entre https y http, y van a necesitar un poquito de maquillaje antes de que pueda hacer algo con ellas.

    2. El servidor de imágenes

    Nuestro servidor de imágenes (czcdn.com), desafortunadamente no aceptaba contenido seguro.

    Desde hace unos meses he estado hospedando el contenido desde CloudFlare, el cuál actúa como un proxy cache y se encarga de servir las peticiones que llegan. El único inconveniente con esto es que no tiene un soporte (a un precio razonable) para https.

    Así que la noche de hoy, he decidido cambiar, y utilizar otra CDN diferente, una que tenga soporte para https integrado. Así que, después de sacar la billetera y pagar por un contrato anual, ya tengo un servidor de imágenes para https. Lo que significa que podré servir sin problema todas las imágenes bajo https de forma distribuida.

    3. Las redirecciones

    Ahi vamos. Todavía al cargar la página principal hay un híbrido entre http y https. Con un poco más de trabajo el 100% de contenido va a estar en https por fin. Una vez que lo logre voy a mudar a que todos los usuarios registrados utilicen https. En el mejor de los casos ni siquiera se van a dar cuenta, ellos simplemente teclean "cemzoo.com" y siguen navegando el sitio como si nada ocurriera


    ... Pero de fondo, su conexión está siendo encriptada y va por un canal seguro.
    a £x£, Velli, Steiner y 4 más les gusta esto.
  • Kentaurus
    El día jueves estuve "optimizando" la base de datos. Debido a que mi configuración ya data de hace buenos años, sonaba razonable optimizar la base de datos para que haga mejor uso de los recursos del sistema.

    Puedo decir que eso no resultó en lo mas mínimo. Esta mañana me desperté, saludé a Tania, abrí CemZoo, y estaba caído. Sigh. Nada abría. Error 502 Gateway tanto en CemZoo como en PRO, que es el error que aparece cuando se acaban los handlers de PHP, y se habían terminado porque todos estaban ocupados intentando conectar a una base de datos que no existía.

    Sobra decir que mi base de datos estaba entretenida intentando escribir 8Gb en disco duro .. una, y otra, y otra vez. Tanto así que me tiró, y no me dejó entrar. Tuve que hablarle a soporte técnico y decirles "¿alguno de ustedes, podría ir y darle una patadita a mi servidor?". Cosa que hicieron. Y después de patearlo un par de veces comenzó a responder ....

    ... Excepto por la parte de red, que no respondía. Y luego los procesos de PHP seguían en el limbo. Y luego entró a CZ e intento pone run post para que me diga "la tabla de búsquedas está dañada".

    Argh.

    No es la mejor forma de pasar un fin de semana, pero por durante unas 2-3 horas he estado corriendo y revisando para restaurar todo. Ahora está estable.

    La nueva arquitectura que estoy probando tiene un servidor dedicado a base de datos. Lo cuál hace que si se cae CZ, o PRO, o el wiki, no pasa nada.

    Con la excepción de que .. si se cae la base de datos ....
    Se cae todo.
    a JuanRando, koneko nyan y Haruhi les gusta esto.
  • Kentaurus
    El protocolo http es un protocolo ya viejo, después de todo data de los 70's. Para efectos de internet, eso es una eternidad. Tuvo una revisión, HTTP/1.1, y desde entonces, es lo que hemos estado usando.

    Hay héroes anónimos. Las personas que diseñaron el internet como tal (el protocolo TCP, el protocolo IP, el protocolo HTTP, los protocolos de ruteo), fueron unos genios. Unas de las mentes más brillantes de nuestra época, que probablemente no recordaremos, de la misma forma que no recordamos quien inventó el retrete del baño.

    Hace algunos meses, los ingenieros de Google, en su ataque de ego y pensar que son dueños del internet, se pusieron a rediseñar un nuevo protocolo. Tuvieron el descaro de decir que HTTP está obsoleto y que van a hacer su propio protocolo. Considerando que son dueños de Chrome (el cuál ya casi el 50% de las personas está usando), y que TODO mundo entra a Google, básicamente nos tienen secuestrados.

    "Si, amo Google, hablaré el idioma que tu me digas."

    Y Google diseño un nuevo protocolo de nombre: SPDY
    Y lo adoptó con Google Chrome, y en sus servidores con Google, Gmail y demás

    ... viendo esto, y para no quedarse atrás, Firefox desde la versión 13 lo adopto también.

    Microsoft tiene ingenieros orgullosos y que no se dejan llevar por las payasadas de la gente de Google, e Internet Explorer no tiene soporte.
    Apple tiene ingenieros con cosas que hacer, y qe no se dejan llevar por las payasadas de la gente de Google, y Safari no tiene soporte.

    Así que, Chrome, Firefox y Opera son los navegadores que soportan SPDY.

    El protocolo, sin embargo, es exitoso. Tanto así que en el diseño de HTTP 2.0 (la evolución del protocolo HTTP), están tomando varias de las ideas de Google. Cosas como comprimir encabezados, una sesión SSL y forzar un keepalive.

    Los sitios web en internet no simplemente pueden comenzar a utilizar SPDY, hay una serie de pasos necesarios para habiliar el protocolo, y no todos los servidores lo soportan. Apache tiene mod_spdy que se puede usar para habiltarlo, y nginx lo soporta de forma nativa.

    Esto se le deja al webmaster que debe instalar el módulo de spdy. Una vez que la persona lo instalé navegadores con soporte (como Google Chrome), lo comenzarán a utilizar automáticamente. En lugar de utilizar el confiable HTTP, comenzarán a usar SPDY. Todo va encriptado, así que es una mejora considerable en seguridad. Y hay compresión predeterminada, así que el desempeño es un poco mejor.

    .....

    El día de hoy, después de varias tribulaciones, terminé de instalar SPDY en el servidor. Si utilizan Google Chrome, y entran a



    Su navegador comenzará a utilizar SPDY automáticamente (por favor, noten el https)

    SPDY es mucho más seguro. Después de todo, es https, todo va encriptado. Esto es una prueba, voy a comenzar a experimentar con algunos usuarios (tipo prueba A/B) antes de decidir prenderlo de forma predeterminada para todo mundo. Pero por mientras, los que quieran probarlo, disfruten la velocidad.
    a Tania, koneko nyan, Velli y 1 persona más le gusta esto.
  • Kentaurus
    Con la migración de CemZoo de Abril, compré un par de mounstros. La idea era que alcance para el futuro. Y bajo la política de "más vale que sobre y no que falte" decidí comprar uno de esos servidores tipo "que cuando la abrace no la abarque".

    Así que compré un servidor con 8 cores y 16 gigabytes de RAM. La idea era que el servidor fuera lo suficientemente potente para correr el wiki, pro, el foro, y los blogs.

    Además, he estado utilizando herramientas avanzadas, en estos días, ya es perfectamente posible decirle al servidor "de los 8 CPUs que tienes, PRO solamente va a utilizar ESTOS dos, y de los 16 gigabytes que tienes, solamente va a utilizar ESTOS cuatro".

    Esto evita que una sección del sitio de repente se "coma" los recursos de otra.

    Y por eso, para el arranque de PRO, dado que no sabía que tanto iba a demandar, decidí darle 2 CPU completos, acceso compartido a otros 2 CPU, y 2Gb de RAM. Fue más que suficiente. Para los usuarios en línea uqe hemos tenido y el tráfico, mientras monitoreaba el servidor veía la carga ... 5%... 6%. Creo que le voy a tener que quitar 2 CPU porque no los necesita.

    ------------------------------------------------------
    ------------------------------------------------------

    Tenemos planes.

    Esta vez, debido a que no sabía cuantos jugadores esperar, solamente abrimos un servidor de PRO. Pero no hay nada que nos detenga a abrir uno segundo, o un tercer servidor. Tal vez en un futuro, el próximo año, u organicemos un servicio de rushers.

    Pero es bueno saber que por ahora, la capacidad está ahi.
    a Neliel, koneko nyan, Haruhi y 6 más les gusta esto.
  • Kentaurus
    Eran las 8 de la mañana.

    Seguía mi rutina de ... darle un golpecito a mi despertador (snooze, snooze), antes de levantarme. En eso recordé que tenía una junta con mi jefa. "Nueve de la mañana en punto, en la oficina", me dijo, "ni un minuto tarde". Después se corrigió, "bueno, yo voy a llegar 15 minutos tarde". OMG, voy tarde. Hoy no toca rasurarse, pensé, y me apresuré.

    Tiré las cobijas a un lado, me incorporé de un salto. Y dije, ¿por qué me duele tanto el pecho? El bench press de ayer, recordé. Me dirigí a mi escritorio, prendí la computadora. Cemzoo.com, tecleo. Nada. Nada aparece. Sigh. ¿Habrá tirado Velli el sitio? Nope. Hora de abrir una terminal. Un ping. Nada. Otro ping. Nada. ¿que pasó aquí?

    Hago un ping a la puerta de enlace de mi ISP. Nadie responde. Quiero reportar el error, pero, el sistema de ayuda está en la red de mi host, por supuesto, a la cuál no puedo acceder por que está caída. "Diántres, esto es como reportar que no tienes línea telefónica .. por teléfono". Ops.

    Un poco más de debuggear. Ya voy tarde. Sigh, ¿no toca bañarse? Imposible, tengo una junta importante, una presentación con 20 personas de mercadotecnia que ven los productos a nivel regional y van a revisar la nueva estrategia de promoción. Siiiiiiigh.

    Ok. A correr.

    Voy tarde. Llego a la oficina. 9:15. Mi jefa no está. Esbozo una sonrisa al darme cuenta que le he ganado en llegar. Ya la imaginaba en la puerta, golpeando suavemente al piso con su pie, mientras me ve con sus ojos marrones y me dice con su acento Indio "9am, man". Pero nada de eso. Me dirijo a mi escritorio, y me tiro en él. Tomo mi mochila, y saco mi Macbook, la pongo en el escritorio, abierta. El ping que dejé corriendo sigue ahi. Nunca lo detuve. CemZoo sigue caído.

    9:30. Mi jefa no llega.
    9:40, suena el celular. "Voy tarde", me dice ella. "You don't say", pienso, pero respondo "No se preocupe".

    10am. Hora de mi junta. CemZoo sigue caído. Pude entrar por un segundo pero ya no más.

    Me contacta Wicho por Facebook. Me dice "Hice un post en el foro" (¿omg, ya regresó?), "Pero después se cayó" (sigh). Sobre la CemZoo Radiostation. Me quejo un rato con Wicho, pero no lo entretengo mucho, seguro el también está ocupado. Pongo mi atención a mi junta, tengo un grupo de 20 personas que me están preguntando muchas cosas.

    ..... Mediodía, nos traen pizza. No es tan cool como parece. Cuando veo llegar 15 cajas de pizza esa es mi señal de "eso significa que no podemos ni siquiera salir de la sala de juntas". Eso hacen los jefes, cada vez que no quieren que salgas ni te muevas, te llevan comida, así no tienes excusa para irte. Suficiente comida para que no tengas hambre, no tanta como para que te duela el estómago.

    Es mediodía (pero tarde en casi todos lados del mundo, por no decir noche en España). Logro entrar a la empresa a quejarme del servidor. Tienen problemas de red (You don't say). Me piden disculpas. No me interesan las disculpas, me interesa que restauren CZ que lleva horas caído. Abro mi computadora, empiezo a buscar servidores en otro lado. Bah. Todo es caro.

    Recuerdo que existe Facebook. Publico un estatus de que CemZoo está caído (ja, como si no supieran ya). Pero por lo menos para que vean que estamos enterados y trabajando en restablecerlo, "¿para esto me mudé de host?", pienso. Andros se burla de mi post. Lo merezco. "Hey, CZ no se cae tan seguido", "ok, ¿a quién engañas Rigel?, parece bebé empezando a caminar"


    Doy otra mordida a la rebanada de Pizza, dejo la laptop a un lado e interrumpo a alguien de Singapur que está diciendo tonterías. "No, eso así ha estado siempre". "Si, siempre hemos vendido eso". "No, ese tipo de tinta no existe". Sigh, necesito otro trabajo.


    ......... ¿A que hora se restauró CZ? No tengo idea. Sólo se que espero que no suceda más seguido o tendré que buscar un nuevo host ;)

    Ya estamos de vuelta.
    a Meelissa, koneko nyan, Kibary <3 y 4 más les gusta esto.
  • Kentaurus
    El día de hoy estuve en actitud obsesiva, intentando disminuir el tiempo de carga de la página principal de CemZoo.

    Había en particular un query que me estaba molestando, que sólo ocurría en CZ y que recuperaba la información de los estilos ... cada vez que se carga la página. Este query estaba agregando casi 200 milisegundos a la carga de cada página.

    Después de un buen rato de depurarlo, me di cuenta de la razón.

    ¿Y es? Memcache está configurado solamente para guardar objetos de hasta 1Mb, y debido a que tenemos en CZ poco más de 12 estilos (no todos activos), la cantidad de datos que se intentaban guardar estaba ascendiendo a los 1.3Mb. Discutible también es deserializar un objeto de 1.3Mb (dejaré eso para después).

    Esto me dejaba con dos opciones
    1) Habilitar compresión para el caché del foro (gasto de ciclos de CPU)
    2) Habilitar memcache para almacenar más de 1Mb (gasto de memoria)

    Me he decantado por el segundo, y he asginado objetos en memcache de hasta 2Mb de tamaño.

    Y... puedo decir, que ahora la página tarda en cargar 150-200 milisegundos menos. Esto es una mejora increíble en el tiempo.
    a Betta Moko-chan y Dark Lady les gusta esto.
  • Kentaurus
    Después de un largo rato de ir y venir con nuestro equipo de red del Datacenter, por fin terminamos de arreglar la configuración de red.

    La razón por la cuál CZ iba tan lento es porque ... en lugar de conectarlo al ruteador, por error conectaron el servidor a lo que puedo definir como una hogaza de pan. Y el pan no transfiere muy bien los bits, así que se estaban atorando. Me ofrecieron ponerle mermelada, pero tuve que insistirles en que lo cambiaran mejor por un switch de red.

    Y una semana después :) Ya estamos.

    Simplemente, el throughput no era el adecuado. El sitio estaba intentando servir el tráfico con un máximo de 10Mbps por segundo, y después de hacer las actualizaciones pertinentes, el día de hoy entre a ver el uso y ... quedé sorprendido, se acerca a los 30Mbps. No cabe duda, si estábamos 3 veces abajo de lo requerido, que el foro estuviera lento.

    Screen Shot 2013-03-30 at 1.53.44 AM.png
    a Haruhi, koneko nyan, Vampichoco y 5 más les gusta esto.
  • Kentaurus
    Durante muchos años hemos estado corriendo CemZoo con un servidor que le daría risa a distintas personas que les contara. Generalmente en una conversación, cuando les cuento en que corre CemZoo, les digo:

    Es un Dual Core, con disco duro de 70Gb y 2Gb de RAM

    E INMEDIATEMENTE la respuesta que obtengo de la persona a la que le cuento, es, casi siempre una variante de "mi computadora tiene más poder que eso"

    .... y en estos tiempos me dicen "Oh, eso es lo que tiene mi iPhone, casi, el mio es de 64Gb"

    Dejaré para una entrada posterior explicar cuáles so las diferencias principales entre una computadora "normal" y un "servidor', porque aunque los conceptos son similares hay algunos detalles que cuentan muchísimo.

    Durante años he estado usando mi fiel servidor. Además, he hecho mucho de lo que yo llamo "trabajo invisible", y esto es, trabajar de fondo en optimizar el servidor para que corra sin problemas para la cantidad de tráfico (millones de visitas) que tenemos usualmente.

    Estos días, tuvimos una migración de servidor. Como parte de la migración cuadruplique la capacidad del sitio, para prepararme para distintas cosas, y sobre todo, porque los precios de los servidores han caído considerablemente y simplemente, hacía sentido.

    Y entonces prendí el sitio y ... oh, terror, iba más lento que una conversación entre dos Slowpoke.

    Un par de cosas:

    1) Aparentemente uno no puede replicar 2 años de optimización en un solo momento, con el nuevo hardware, todo tenía que ser tuneado de nuevo, las asignaciones de memoria a los servicios, la prioridad de los procesos, los IPC, etc, etc, etc

    2) Tuve tanto cuidado de elegir el hardware adecuado, que se me olvido revisar como lo estaban instalando, y cuando me di cuenta, tenía yo un ruteador enmedio de mis dos servidores ... sigh. ¿Tiempo de conexión a la base de datos? 6 segundos.


    Así que he estado haciendo algunas optimizaciones por mi cuenta, y para las que no puedo hacer, mandando y regresando tickets con soporte técnico en el data center donde tenemos nuestra infraestructura. El día de hoy, el sitio está funcional.

    Tenemos todavía muuuuchas cosas pendientes, la red no está 100% optimizada y necesito que me cambien el modo de red a full duplex (tengo la teoría de que el servidor está conectado a un pan bimbo en lugar de a un switch). Van a ser unas semanas interesantes.


    En conclusión, cambiar de hardware no es la solución "mágica" para que todo vaya más rápido. Sobre todo cuando el hardware anterior funcionaba decentemente. Pero poco a poco vamos restableciendo todo.
    a koneko nyan, Meelissa, Dark Lady y 2 más les gusta esto.