ActiveRecord conoce a NeverBlock

Luego del revuelo que provocó la salida de NeverBlock a la comunidad de desarrollo Ruby/Rails, hubo gente que se dedicó a reimplementar ActiveRecord utilizando los beneficios de NeverBlock. Al día de la fecha, ActiveRecord solo incluye el adaptador neverblock-postgresql-adapter. Esta solución le permite a ActiveRecord realizar consultas en paralelo, como si se tratase de un sistema de multihilo, pero a diferencia de estos, tiene ciertas ventajas:

  • Las Fibers consumen menos recursos que los hilos por lo que esta solución es teóricamente más rápida.
  • NeverBlock no requiere de full thread safety, al evitar el uso de variables globales y estáticas para los estados trancisionales.
  • Se integra fácilmente con programas basados en eventos eliminando la caída de rendimiento que sucede con la introducción hilos en dichos ambientes.

Se realizó un benchmark contra un adaptador postgresql plano usando diferentes cargas de trabajo, las cuales fueron categorizadas como sigue:

Very Light : una sentencia count simple

Light : un count y un create

Moderate : 2 counts y un  create envueltos en una transaccion que realiza rolls back

Heavy : 3 counts, un create y un update envueltos en una transacción que commitea

Very
Heavy : 3 counts, un count condicional (en un campo no indexado), un create y dos updates todos envueltos en transacciones que commitean

Todo fue aplicado 1000 veces.

Los resultados fueron como sigue a continuación:

Como se puede observar, NeverBlock::AR es persistentemente más rápido que vanilla AR.


 

Poro otra parte, se realizó otro benchmark para testear los efectos del incremento de conexiones a NeverBlock::AR. Se testearon con 2, 4, 8, 16 y 32 conexiones.
El benchmark consistió de ejecutar por primera vez "select 1" 5000 veces y luego correr "select sleep(1)" 20 veces para cada configuración.

 

Como probablemente se puede adivinar, el numero incremental de conexiones concurrentes tiene muy poco efecto si las consultas son todas muy rápidas (nadie puede vencer a "select 1"), pero si todas las consultas son lentas, se podrá duplicar el rendimiento simplemente duplicando la cantidad de conexiones.

fuente: oldmoe