Como viene siendo habitual los Lunes, os traemos un nuevo lanzamiento. A diferencia de la anterior semana, no hemos introducido cambios en la interfaz web, pero si distintas mejoras en estabilidad y rendimiento.

Como se ha señalado en entradas anteriores, estamos experimentando con le función WAL de SQLite, la cual permite una mejor concurriencia y así ASYD funciana de forma más óptima. Era el momento de profundizar en esto ya que estuvo causando algunos comportamientos inesperados.

Una de las cosas que hemos notado es que la versión SQLite distribuida en estable de Debian, es anticuada: la 3.7.13 es la última y la actual es SQLite 3.8.8.3, y algunas de las funciones que usabamos no están disponibles en esta versión.

Hemos cambiado todo esto de forma que ahora ASYD es totalmente compatible con SQLite 3.7.13, pero es altamente recomendable actualizar a SQLite 3.8.8 ya que ofrece un mejor rendimiento que la versión antigua.

Importante: Cuando actualices a la nueva versión de ASYD, actualiza también tus gemas (actualizar gemas) para obtener la última versión de Phusion Passenger, actualmente 5.0.4, como algunas funciones dependen del nuevo Passengerfile.jason, esto nos permite distribuir algunas configuraciones internas para Passenger.

Instrucciones completas de actualización (desde el dentro del directorio ASYD):

passenger stop
gem update
git pull
bundle install
passenger start

Activar Checkpointing de WAL

Esta es otra de las nuevas funciones que hemos introducido, para evitar operaciones constantes de sincronización que incrementan las operaciones de lectura y escritura en el disco, las bases de datos más activas (notificaciones, tareas y hosts) son checkpointeadas continuamente.

Como funciona?

Todas las operaciones de escritura en las bases de datos son guardadas en la memoria. Un proceso en segundo plano comprueba periodicamente si la base de datos ha sido escrita y has estado inactivo más de 10s egundos (lo que quiere decir que la escritura se ha detenido o que esta se da con mesnos frecuencia). En este caso, checkpointeamos la base de datos, realizando una operación de sincronización en el disco y escribiendo todos los cambios.

Esto proporciona ventajas en el rendimiento, ya que todas las escrituras se realizan en memoria volátil lo cual es mucho más rápido y además requiere menor número de operaciones de lectura/escritura, y evita cualquier posible corrupción de base de datos, debido al multithreading. Por otro lado, esto también tiene una desventaja: En caso de perdida de potencia, las últimas escrituras no quedaran en el disco, pero dicho esto, si hay perdida de potencia en mitad del lanzamiento de un deploy, no necesitarás las notificaciones ya que probablemente tendrás que lanzar el deploy en esos sistemas de nuevo.

Resumiendo: ASYD es ahora mucho más estable y funciona mejor, pruébalo!

Full Changelog