Archive for the ‘Tecnología’ Category

nginx + fast-cgi: Nueva arquitectura para Voota

31 diciembre 2009

Tras tener varios problemas de servidores en Voota, nos tocó investigar como mejorar los sistemas. Como siempre, lo primero es preguntar a los expertos. Nuestros amigos de amplicate.com y masquemedicos.com lo tenían claro. Junto con muchas otras recomendaciones, nos convencieron para cambiar el servidor web a una arquitectura más moderna.

Adiós Apache y gracias por todo

Apache ha sido durante mucho tiempo (y sigue siendo) el servidor web más utilizado y popular para servir tanto páginas estáticas (html) como aplicaciones desarrolladas en php, perl o python. Pero como pasa con todo, poco a poco ha ido quedándose atrás en favor de otras arquitecturas más modernas.

Nginx

Arquitectura nginx con fast-cgi

Nginx es un servidor mucho más ligero que apache y que, por lo tanto, realiza menos funciones. La idea de es utilizar Nginx en la primera línea de fuego para servir todo el contenido estático del sitio web: Pagínas html, imágenes, javascript, hojas de estilo, etc. El resto de las tareas se delegarán a un servidor específico.

fast-cgi

Es la evolución de CGI (Common Gateway Interface), aquél protocolo concebido allá por 1993 para responder a la demanda de páginas dinámicas. Hoy fast-cgi permite conectar (por tcp) un servidor web estilo Nginx con otro servidor independiente que ejecuta las aplicaciones. En el caso de Voota, estás aplicaciones están desarrolladas en php y el servidor de aplicación es php-fpm.

En resumen, nada radicalmente nuevo. Mismos programas, mismo lenguaje, pero con una arquitectura mucho más moderna, flexible, rápida y escalable.

Anuncios

Mejorando el rendimiento de Symfony a base de caché

17 diciembre 2009

Symfony no es lento

Se dice que utilizar un framework en general y Symfony en particular penaliza el rendimiento de una aplicación web. Es cierto, al menos a priori. Por mucho trabajo de optimización que se haga, las propias clases del framework consumirán tiempo y recursos y tampoco serán las óptimas las queries de acceso a base de datos generadas. Siempre será más eficiente un código personalizado para la ocasión que un código genérico.

Dicho así podría parecer que es preferible invertir tiempo en hacer código a medida que utilizar herramientas como Symfony. Nada más lejos de la realidad. Una de las cosas que proporciona Symfony, y que compensa con creces “su lentitud”, es un sistema de caché que con muy poco esfuerzo permitirá a una aplicación desarrollada en Symfony “correr” mucho más rápido que una aplicación hecha “a mano”. ¡Ojo! Esto no quita la responsabilidad de hacer un código eficiente.

Activando la caché de página

Efectivamente, hay muchas formas de optimizar el rendimiento de una aplicación, pero sin duda, la caché de página es la que marca la diferencia. Para activarla en Symfony solo hay que crear el fichero cache.yml en el directorio config del módulo (ej. apps/frontend/modules/politico/config/) activando la cache para cada acción en la que se quiera poner en caché:

ranking:
 enabled: on
 with_layout: false
 lifetime: 60

show:
 enabled: on
 with_layout: false
 lifetime: 360

“ranking” y “show” son dos de las acciones del módulo. “with_layou: false” indica que sólo ha de guardarse el código específico de esta vista, no el de layout.php. “lifetime” es el tiempo en segundos que tardará en limpiarse la caché automáticamente.

Limpiando la caché manualmente

Symfony proporciona información del estado de la caché si se necesita

Una de las opciones para limpiar la caché de una página es esperar a que pase el tiempo indicado en “lifetime” en el fichero de configuración. Como esto muchas veces no es una opción, Symfony proporciona un mecanismo para limpiarla por código. El siguiente snipplet (pedacito de código) muestra como, en Voota, se limpia la caché de la página de un político cada vez que alguien deja un comentario:

$cacheManager = $this->getContext()->getViewCacheManager();
if ($cacheManager != null) {
$cacheManager->remove(“politico/show?id=”.$politico->getVanity().”&sf_culture=es”);
$cacheManager->remove(“politico/show?id=”.$politico->getVanity().”&sf_culture=ca”);
}

La clase sfViewCacheManager permite interactuar con el sistema de caché de Symfony. El método “remove” limpia la página que se quiera.

Más rápido incluso

Otra de las funcionalidades que ofrece Symfony es delegar la gestión de la caché a un sistema externo. Unos de los sistemas más conocidos y utilizados dentro y fuera de Symfony es memcached. Una buena idea será dejarle la gestión a él. Esto se configura en el fichero de factorías de la aplicación (apps/frontend/config/factories.yml):

dev:
 view_cache:
  class: sfMemcacheCache
   param:
    lifetime:                  86400 #24h
    prefix:                    vo
    servers:
     server_01:
      host: localhost
      post: 11211

El resto exactamente igual. No será necesario tocar ni una línea de código para esto.

Desarrollo web, desarrollo ágil

13 octubre 2009

Para que “algo” funcione en internet tiene que ser ágil desde todos los puntos de vista. Las páginas web deben pesar poco, el tiempo de respuesta desde que se pide una página hasta que se muestra en el navegador tiene que ser casi inmediato y, dentro de un sitio, si una página ha de ser visitada, más vale que se acceda a ella en pocos clics. Afortunadamente estos conceptos ya han sido aceptados y digeridos por la mayoría de profesionales que se dedican a la “construcción de internet”.

Sin embargo, muchas veces es obviado el concepto de agilidad en la fase de desarrollo. Aunque existen muchas formas y metodologías para aplicarlo, una vez más, lo más importante es aplicar la lógica y entender bien lo que se está haciendo para poder llegar a ser “ágiles”. Se trata de aplicar unos conceptos fundamentales que cada metodología implementará de una manera. Algunas metodologías son Scrum, Programación Extrema (XP) o Agile Unified Process (AUP).

Scrum: Procesos y elementos

Scrum: Procesos y elementos

¿Qué es desarrollo ágil?

Según el manifiesto para el desarrollo ágil de software, éste se basa en 4 pilares básicos:

  • Somos un equipo. Poco aportan unos procedimientos muy estrictos y las herramientas más caras del mercado si el equipo de desarrollo no sabe utilizarlos. Se trata de repartir coherentemente las responsabilidades y el trabajo del desarrollo. Debe haber una cabeza sin duda, pero la implicación y  motivación de cada miembro del equipo es decisiva para el éxito del proyecto. No será fácil aplicar este concepto si se piensa únicamente en horas/hombre (horas/recurso) como un activo del proyecto.
  • Hacemos software, no documentos. El segundo principio dice que hay que dar la importancia justa a la documentación. Si se pretende hacer una documentación exquisita con extensos documentos funcionales que recojan todas y cada una de las necesidades de la aplicación, ocurrirá una de estas dos cosas: En el mejor de los casos, el producto final no se parecerá en nada a lo planteado en estos documentos, o, en el peor, el desarrollo no empezará nunca.
  • Tendremos que hablar con el cliente. Para muchos esto es lo más duro. Trabajando en consultoría es frecuente oír decir que el cliente no sabe lo que quiere, que las especificaciones son malas, que no saben nada de informática o que cambian de opinión cada dos por tres. Seguramente, pero “that’s life”. La solución no es fácil, pero todo pasa por ser flexibles, no hacer rígidos planes al principio y sí hacer continuas iteraciones para ver que se ha hecho y que se va a hacer. Siempre con la aprobación y colaboración del cliente.
  • Ooops, algo ha cambiado. Esta es la piedra filosofal del desarrollo ágil. Hay que estar listo para el cambio. Las iteraciones de desarrollo deben ser cortas. Estar preparado para cambios de prioridades.

En resumidas cuentas, para hacer una super-aplicación, habrá que empezar haciendo un programita, mostrarlo al cliente (aunque sea interno en la empresa), recoger las sugerencias y cambios y preparar la siguiente iteración (seguramente es suficiente con una pequeña lista de tareas). Iteración tras iteración se llegará a la super-aplicación, pero mientras tanto ya tenemos algo. No olvidar nunca que estas iteraciones deben ser cortas (Scrum propone 2 semanas – 1 mes). Si no da tiempo a hacerlo todo en el tiempo prefijado, seguramente habrá alguna tarea que se pueda dejar para la siguiente iteración.

La importancia del backup

29 septiembre 2009

Partiendo de la base de que, en este negocio, todo puede fallar, hay que tener siempre un plan B para cuando la cosa se pone realmente “mal”. Normalmente se intentará evitar siempre llegar a una situación en la que sea necesario “tirar” de la copia de seguridad. Sin embargo, tener un buen backup ofrece ventajas únicas. Hacer copias de ficheros no tiene ninguna dificultad, preparar una buena estrategia sí. Veamos una serie de puntos fundamentales a tener en cuenta antes de diseñar una buena estrategia de backup para el servidor donde se aloja nuestro preciado sitio web.

No es tan importante el dispositivo físico como una buena estrategia

No es tan importante el dispositivo físico como una buena estrategia

  • Cualquier tipo problema. Un backup debe proteger ante cualquier eventualidad.
    • Un fallo de software o de programación puede hacer, por ejemplo, que la base de datos se vaya degradando paulatinamente. Sería deseable guardar una serie de estados (“fotos”) desde, al menos, el día que empezó a corromperse la información. Una copia diaria de la base de datos durante el último mes puede ser suficiente para un sitio web “vivo”.
    • Hardware. Un error común es no hacer copia de un disco duro porque está en raid-1 o espejo. Efectivamente esto salvará la información en caso de que uno de los discos se rompa, pero no lo hará en el caso de que los datos se hayan borrado por cualquier otra razón (errores de software, virus o ataques). Otro error habitual es hacer la copia dentro del mismo disco o del mismo equipo informático. Cuando es este disco o este equipo el que se rompe, de poco sirve la copia.
    • Virus, gusanos, ataques mal intencionados, etc. En realidad se podría tratar este problema como una forma combinada de los dos anteriores.
    • Catástrofes imprevisibles. Incendios, robos, etc. Si se produce un incendio o un robo en la oficina, tener el backup en otro datacenter, oficina o en casa será suficiente. Y esto escala bien, es decir, cuanto más lejos mejor, tanto lógica como físicamente. A una mente paranoica el tener la copia de seguridad en otro país le daría la seguridad de que sus datos estarán a salvo incluso frente a una guerra por ejemplo 😮
Entonces, para que un buen backup soluciones cualquier tipo de problema, hay que hacer copias periódicas. También hay que guardar el historial, hacer la copia en otro equipo físico y guardar los archivos de ésta en una localización diferente a los datos originales
  • Toda la información. A la hora de diseñar la estrategia de copia, es vital listar todos los datos que es necesario proteger. Ficheros de datos, imágenes, ficheros de configuración, bases de datos o repositorios de software. Igual de importante es tener en cuenta que la información que se va a copiar evoluciona con el tiempo y no siempre se va a copiar la misma información. Es necesario, pues, tener un mecanismo que permita mantener esta “lista” de elementos a copiar “viva”.
  • La estrategia. Con los puntos anteriores claros, preparar una estrategia se convierte en una tarea trivial. Definir a que hora se hará (seguramente cuando haya menos usuarios/tráfico) y donde se copiará la información físicamente. Una cosa importante a tener en cuenta es que, casi siempre, se trabaja con ficheros a la hora de hacer el backup. Por eso es importante que, la información que no lo es se pueda convertir antes a fichero. Un ejemplo claro son las bases de datos que, por lo general, tiene su propio sistema de backup. Otra decisión importante es si el backup debe estar cifrado o no. Aunque suene necesario, lo cierto es que muchas veces no compensa.
Para asegurarse que se copia toda la información es tan importante definir bien al principio lo que se va a copiar, como hacer revisiones periódicas de que información nueva debe ser copiada.
  • Recuperable. No sirve de nada tener una copia de seguridad que no se puede restaurar. Parece algo evidente, sin embargo es sorprendente la cantidad de veces que ocurre que al intentar recuperar un dato copiado, el backup está corrupto, vacío o simplemente se descubre que el backup ¡nunca se ha hecho! Ojo también al utilizar cifrado para almacenar las copias. Siempre debe haber, al menos, dos personas con la llave y/o la contraseña y asegurarnos de que realmente es así
La única forma de asegurarse que la información está correctamente guardada es hacer “simulacros” restaurando el backup de vez en cuando.