Lucene, Grids, Heaps y otras cosas del montón

En el penúltimo post explicaba la importancia en ciertos escenarios de que los objetos tengan una vida de corta duración. Only the good die young. Uno de esos escenarios es el caso en el que tengamos una Heap enorme, caso en el que la recolección de basura puede llevar mucho tiempo.

¿Y qué tamaño puede tener uno de esos Heaps tan enormes? Recuerdo hace años que tener un Heap de 512Mb ya era la caña. Después, cuando estabamos haciendo aplicaciones de trading hace ya casi cinco años, jugábamos con Heaps de 4gb, que no estaba mal pero ya resultaba bastante pequeño, pero era fruto sobre todo de las limitaciones de los sistemas operativos de 64 bits y en producción si que nos íbamos a 8, pero con la incertidumbre de no saber con exactitud que iba a pasar.

Escribiendo micro-benchmarks con jmicrobench

Tal y como escribía hace unos días, mi opinión es que los microbenchmarks no son una técnica recomendada para sacar conclusiones sobre el rendimiento global de nuestros programas.

Sin embargo sí que existe una serie de circunstancias en las que es importante el conocer el rendimiento de tu lógica de negocio. Por ejemplo cuando estamos trabajando en sistemas que requieren procesar una gran cantidad de transacciones por segundo. Imaginaros quizás un sistema de pagos por Internet, o el software de una casa de apuestas, o la línea de almacén de un gran fabricante de lo que sea.

En estos casos no sólo es necesario el tener la confianza en que el software va a soportar el volumen esperado sino que es necesario garantizarlo. ¿Cómo lo podemos garantizar? Con tests. Pero hacer los tests puede ser complicado. Por eso se hacen útiles frameworks para la creación de microbenchmarks como jmicrobench del que nunca había oido hablar pero que en breve os contaré en otro post como he llegado a el.

jmicrobench es una extensión de jUnit que define un nuevo ejecutor de Tests: PerformanceTestRunner que se encarga de ejecutar nuestros tests y de calcular el número de operaciones por segundo que ejecuta, su media, e incluso de generar gráficas. Un test de rendimiento se crearía de la siguiente forma:

GC: Only the good die young

Una frase popular dentro del frikimundo de la Garbage Collection es "Only the good die young", que proviene además de una canción bastante popular de Billy Joel y que le viene que ni pintada.

Un poco de background para la frase. Todo esto depende de la máquina virtual utilizada, pero tomando como referencia Hotspot que es una máquina virtual generacional, tenemos que la memoria se divide en dos generaciónes: Young generation y Tenured generation. Cada una de estas zonas a su vez está dividida en otras zonas, pero esto lo vamos a obviar por razones de simplicidad.

La Young Generation es mucho más pequeña que la Tenured Generation. Por lo tanto, la recolección de basura ahí es mucho más rápida. Pero aún más importante, la recolección de basura en la Young Generation se hace constantemente y no requiere parar los diferentes threads de la máquina virtual de Java, mientras que normalmente (recordad, esto es una visión meramente pedagógica y simplificada) la recolección de basura en la Tenured Generation exige parar todos los threads de la máquina virtual.

¿Qué has hecho este verano? Soy programador

Una de humor para el Martes. Supongo que es viejo pero me lo he encontrado y me ha hecho mucha gracia. ¿Qué has hecho este verano?

La historia de Monster

Mr. Jordi Monné me avisa de que en Mixergy entrevistan a Jeff Taylor, el fundador de Monster.com. El señor Jordi es muy listo porque sabe que si me lo dice yo haré un resumen y así no tendrá que verse la entrevista. ¿Verdad? Verdad. He tomado unas notas de lo que ya es historia de Internet.

¿Cómo se crea el mayor imperio de clasificados de empleo del planeta? Atendiendo a la entrevista mi respuesta sería siendo el primero. En 1993 Jeff Taylor era dueño de una agencia de clasificados tradicional. Una agencia de publicidad enfocada en la colocación de personal. Es decir, gran empresa busca gente y ellos se encargan de poner los anuncios en los periódicos. Ni siquiera era una agencia de contratación. Pero les iba muy bien. Hacían 400.000 dólares al año.

Pero tras la crisis algunos de sus clientes tenían problemas, así que le dijeron: "O buscas formas mejores de anunciarnos o buscaremos quien lo haga por ti". Eso sí es motivación. Y a Jeff se le ocurrió crear una BBS (todavía no había webs), y llamarle Monster. Monster viene de la idea de tener una base de datos monstruosa. Lo que pasa es que pronto se dio cuenta de que no le llegaba con la BBS, porque quería imagenes, así que le pasaron el contacto de una empresa que hacía cosas para un sistema que se llamaba Mosaic (seguían sin existir las páginas web). Y así empezó todo. Monster fue el dominio 454 en ser registrado y cuando empezó todo sólo existían 200 páginas web en el mundo.

Lecciones sobre AWS aprendidas en Netflix

Tal y como escribía hace unos días, la arquitectura de Netflix está basada en Amazon Web Services. La compañía, decidió a principios de año migrar su arquitectura a Amazon.

En el blog de Netflix, comparten cinco lecciones que han extraído de su experiencia al mover su arquitectura desde su propio data center a la nube:

Notas sobre la arquitectura de Facebook Chat

En la línea de las notas de arquitectura que suelo publicar voy a escribir hoy un post con un resumen de notas que he ido sacando sobre un documento acerca de la arquitectura del chat de Facebook. Si os interesa el tema entonces os pueden interesar también las notas sobre la arquitectura de Facebook del año pasado. Empiezo.

En 2007 en Facebook se dan cuenta de que necesitan un Chat, seguir los mensajes entre muros es un infierno. El código surge en el 2007 de lo que en Facebook denominan un Hackathon, es decir quedarse los ingenieros durante toda una noche programando. No es hasta el 2008 cuando se manda el primer mensaje y lo lanzan oficialmente.

Las estadísticas del chat dan miedo:

• 800+ million user messages / day


• 7+ million active channels at peak


• 1GB+ in / sec at peak


• 100+ channel machines

McMafia

Durante estos días ha tocado irse de vacaciones, y más importante he pasado unos días en el hospital por una operación de rodilla que tenía pendiente desde hace unos añitos. Así que me ha quedado bastante tiempo para leer.

Uno de los libros que he leído es McMafia. Se trata de un libro no relacionado con la informática que le gustará a todos aquellos a los que les guste el tema del crimen organizado.

El libro resulta algo difícil de leer por la cantidad de nombres y hechos que aparecen que hacen que si vas leyendo unas cuantas páginas al día te pueda ser algo complicado seguir el hilo. Yo me lo compré en inglés porque quería que no se me oxide el vocabulario, pero la verdad es que en este caso seguramente obtaría por comprar la versión traducida, ya que como os digo el seguir tanto nombre, tanto hecho y tanta fecha se hace aún más complicado en otro lenguaje.

Documentos sobre seguridad de Microsoft

A todos los que os interese el tema de la seguridad quizás os interese saber que desde Noviembre, Microsoft ha comenzado a publicar una serie de documentos de referencia relacionados con la seguridad en entornos web.

Estos documentos describen diferentes vulnerabilidades e intentan presentarlas de forma que puedan ser comprendidos por personas situadas en diferentes puestos de trabajo: desde el tomador de decisiones al tester pasando por arquitectos y desarrolladores. En el momento de la publicación de este post hay tres documentos disponibles:

Creando mejores tests

Alfredo Casado ha publicado hace unos días en su blog un artículo muy recomendable donde comparte con todos una serie de consejos a la hora de crear mejores tets.

Alfredo nos recomienda tratar a nuestro código de tests como si fuese de producción y además explica una de las funcionalidades más interesantes de JUnit 4.7, que no conocía por cierto, que es la creación de reglas (Rules) que permiten extraer código común que se utiliza en todos los tests.

No cuento nada más. El que quiera saber más que lea su artículo: Escribiendo mejores tests.