Por qué los procesos escalan mejor que los threads

Este es el provocador título de una entrada en el weblog Assaf Arkin. En él se defiende la solución que la comunidad LAMP ha tomado para aplicaciones multitarea (procesos) frente a la de Java (threads). Según el autor, al programar en Java se emplean objetos, librerías, frameworks... APIs, en definitiva. Esto hace que los programadores no se preocupen por nada que "quede fuera de la máquina virtual" porque las abstracciones en las cuales se basan (APIs) son de muy bajo nivel.



Los programadores de LAMP sin embargo suelen construir sus aplicaciones encadenando un montón de pequeños programas. En este caso, el nivel de abstracción no es un API sino una tarea. Para el autor, el nivel de abstracción correcto deben de ser las tareas, ya que centrarse en API, de menor nivel de abstracción, hace que se pierda la visión de conjunto lo cual (aunque no explica de un modo muy claro el porqué) permite escalar mejor a los programadores LAMP.



Respecto al rendimiento de las aplicaciones, ¡también parece ser que los procesos tienen más rendimiento que los threads!. No dentro de una máquina, donde los threads efectivamente ganan a los procesos, pero si en un cluster. Y el motivo parece ser que es que al pensar en tareas (procesos) es más fácil construir soluciones que escalen mejor que al pensar en APIs.



No estoy de acuerdo con los los conclusiones del autor, porque no creo que al programar contra APIs se tenga que perder la visión del conjunto y porque el autor parece no conocer, o ha dejado fuera, la gran cantidad de optimizaciones que hacen los servidores de aplicaciones Java que nunca conseguirá obtener encadenando procesos. Alguna de las ideas que hay detrás de los servidores de aplicaciones se ha tratado de llevar al mundo de los procesos en fastCGI , pero no llegan a ser tan eficaces.



No obstante, el artículo aporta ideas interesantes y merece la pena leerlo.