rafaeska.es rafaeska.es Terminado el Máster de Software Libre y su proyecto. LDAP, P2P, Java y Tomcat en la coctelera. Rafa Eska http://rafaeska.es/algo-que-anadir/-/blogs/terminado-el-master-de-software-libre-y-su-proyecto-ldap-p2p-java-y-tomcat-en-la-coctelera 2011-09-07T06:22:12Z 2011-09-06T19:07:47Z <p> Por fin el mes de Julio pasado terminé el Proyecto de Fin de Máster del <a href="http://www.uoc.edu/estudios/masters-universitarios/software-libre/plan-de-estudios/index.html" target="_blank">Máster de Software Libre de la UOC</a>. He tardado 3 años: con calma; disfrutándolo. La enseñanza telemática esta me ha gustado: tienes la suficiente presión, que te fuerza a estudiar, pero tienes una flexibilidad horaria y de diseño del curriculum bastante buena. La UOC, en general, me ha dejado buen sabor de boca, y alguno de sus profesores bastante buenos.</p> <p> Y con el proyecto, pues friquidiversión a raudales. Su rimbombante nombre:<em> Directorio LDAP descentralizado gobernado desde una red peer-to-peer: LDAP2P</em>.</p> <p> La cosa ha consistido en unos <strong>componentes escritos en Java que gestionan y almacenan datos de servidores LDAP mediante una <a href="http://es.wikipedia.org/wiki/Peer-to-peer" target="_blank">red peer-to-peer</a></strong>. Concretamente una red peer-to-peer estructurada, que está basada en una <a href="http://es.wikipedia.org/wiki/Tabla_de_Hash_Distribuido" target="_blank">tabla de hash distribuido</a> (DHT) entre los iguales de la red. Lo que significa esto es que se almacenan pares de clave valor al estilo de un Tabla Hash normal, pero cada entrada esta replicada sólo en un conjunto de nodos. La red conoce en qué nodo buscar cada clave gracias a algún algoritmo de enrutamiento entre los nodos. Por esta capa de enrutamiento de mensajes, trabajando sobre toda la pila TCP/IP, a estas redes P2P estructuradas se las llama también <em>redes superpuestas</em>.</p> <p> La implementación de red utilizada ha sido <a href="http://www.freepastry.org/" target="_blank">Pastry</a>, aunque configurando y arrancado los nodos desde la biblioteca java <a href="http://ast-deim.urv.cat/easypastry/" target="_blank">EasyPastry</a> desarrollada por mi director de proyecto, <a href="http://deim.urv.cat/~ruben.mondejar/" target="_blank">Rubén Modéjar</a>.</p> <p style="text-align: center;"> <img alt="Enrutamiento de mensajes entre los nodos de una red Pastry según cercanía de IDs" longdesc="Enrutamiento de mensajes entre los nodos de una red Pastry según cercanía de IDs" src="http://rafaeska.es/image/image_gallery?uuid=a69b342e-6a7b-4f41-bb4c-7e140f97d305&amp;groupId=10155&amp;t=1315338357786" style="width: 70%; height: 70%;" title="Enrutamiento de mensajes entre los nodos de una red Pastry según cercanía de IDs" /></p> <p> Bueno, pues este componente que convierte nuestro proceso java en un nodo de una red P2P se instalaba y configuraba dentro del contenedor Tomcat. <strong>Al arrancar tomcat el servidor se integra en la red P2P</strong>.</p> <p> Tras ello, otro componente se encarga de comprobar si tiene un servidor LDAP al que conectarse; si lo hay <strong>saca sus datos (cada rama de usuario del directorio LDAP) y los compara y fusiona con las existentes previamente en la tabla hash distribuida</strong> alojada en la red P2P.</p> <p> Esto es, las supuestas aplicaciones clientes de los directorios LDAP harían sus peticiones LDAP a la red P2P en vez de a alguno de los muchos servidores LDAP que esta red soportaría. En nuestro caso la aplicación cliente era una miniweb de administración del sistema. Se podría resumir así:</p> <p style="text-align: center;"> <img alt="Componentes java del proyecto LDAP2P" longdesc="Componentes java del proyecto LDAP2P" src="http://rafaeska.es/image/image_gallery?uuid=3bd01d10-e9b7-4512-bf73-c3757d3c3f10&amp;groupId=10155&amp;t=1315339001061" style="width: 99%; height: 99%;" /></p> <p>  </p> <p> El proyecto ha sido muy gratificante: Java, manipulación de datos en OpenLDAP, Tomcat, los entresijos de una red P2P estructurada... Algo menos gratificante, el uso de <a href="http://es.wikipedia.org/wiki/Google_Web_Toolkit" target="_blank">GWT</a> para la interfaz web. Se me hace engorroso.</p> <p> En cuanto pueda, publico los fuentes y la documentación.</p> <p> Naturalmente el proyecto no hubiera sido posible sin el apoyo y soporte continuo de su director, Rubén. Desde aquí todo mi agradecimiento.</p> Rafa Eska 2011-09-06T19:07:47Z Usando JMeter para el estrés Web Rafa Eska http://rafaeska.es/algo-que-anadir/-/blogs/usando-jmeter-para-el-estres-web 2010-11-22T13:03:43Z 2010-10-26T10:12:46Z <p> Vamos a dar aquí una guía rápida para realizar pruebas de estrés contra aplicaciones y servidores Web, y una serie de consejos fruto de la experiencia y, como no, de haber cumplido el principio <a href="http://es.wikipedia.org/wiki/RTFM" target="_blank">RTFM</a> para el caso de JMeter, en aquellos gratos momentos de uso de la herramienta.</p> <p> <span style="font-size: 11px;"><a href="#intro">Introduccion</a></span></p> <p> <span style="font-size: 11px;"><a href="#grupohilos">Añadir Grupo de Hilos</a></span></p> <p> <span style="font-size: 11px;"><a href="#petweb">Configurar el Plan para las peticiones Web</a></span></p> <p style="margin-left: 40px;"> <span style="font-size: 11px;"><a href="#list">Configuración del Listener</a></span></p> <p> <span style="font-size: 11px;"><a href="#proxy">Recogiendo los <em>samplers</em> HTTP: el proxy de JMeter y nuestro navegador</a></span></p> <p style="margin-left: 40px;"> <span style="font-size: 11px;"><a href="#filtrar">Filtrar las peticiones recogidas</a></span></p> <p> <span style="font-size: 11px;"><a href="#ejec">Ejecución del Test</a></span></p> <p> <span style="font-size: 11px;"><a href="#result">Leer los resultados del Test de JMeter</a></span></p> <p style="margin-left: 40px;"> <span style="font-size: 11px;"><a href="#summ">Summary Report' e 'Informe Agregado'</a></span></p> <p style="margin-left: 40px;"> <span style="font-size: 11px;"><a href="#arbol">Árbol de Resultados</a></span></p> <p> <span style="font-size: 11px;"><a href="#resumen">Resumen</a></span></p> <p>  </p> <p>  </p> <h2> <a id="intro">Introducción</a></h2> <p> La interfaz gráfica de JMeter es un tanto minimalista:</p> <p style="text-align: center;"> <img alt="JMeter recién arrancado" src="http://rafaeska.es/image/image_gallery?uuid=9ac0112a-cab5-46f7-bd50-478961804ea5&amp;groupId=11369&amp;t=1288088609308" style="width: 95%;" /></p> <p> Su uso se basa en el concepto de Plan de Pruebas (<em>Test Plan</em>) , que es el conjunto de acciones que JMeter realizará cuando la prueba se ejecute.</p> <p> El Plan de Pruebas puede estar formado por <a href="http://jakarta.apache.org/jmeter/usermanual/test_plan.html" target="_blank">varios tipos de <em>items</em></a>: Grupo/s de Hilos, controladores lógicos, <em>listeners</em>, elementos de configuración, etcétera. Vamos a usar aquí los básicos para un Plan de Pruebas para una aplicación web.</p> <h2> <a id="grupohilos"> Añadir Grupo de Hilos</a></h2> <p> El Grupo de Hilos (<em>Thread Group</em>) es el punto de entrada de los tests, ya que representa a los usuarios de la aplicación; por eso, es necesario que haya al menos uno en todo plan de pruebas. Cada uno de los hilos del grupo ejecutará el plan de forma completamente independiente a los demás hilos,&nbsp; y la mayoría del resto de elementos de un Plan de Pruebas, deben estar incluidos en el Grupo de Hilos.</p> <p style="text-align: center;"> <img alt="Grupo de hilos en el Plan de Pruebas" src="http://rafaeska.es/image/image_gallery?uuid=305b43a5-18d4-4264-8f7f-95491cbe7040&amp;groupId=11369&amp;t=1288090088631" style="width: 95%;" /></p> <div class="portlet-msg-info"> <span style="font-size: 12px;"><u>Notas de la GUI</u>: Para añadir elementos al Plan de Pruebas se utiliza el menú contextual (botón derecho) sobre el árbol de la izquierda</span></div> <p> En el <strong>Grupo de Hilos</strong> se configura el <strong>número</strong> (cantidad de usuarios), el <strong>período de subida</strong> y el <strong>contador del bucle</strong>. El primero se explica por sí sólo.</p> <p> El Período de Subida (<em>Ramp-up period</em>) indica cuantos segundos se tardará en alcanzar el número máximo de usuarios: si tenemos 10 hilos y establecemos este período en 100 segundos, JMeter tardará 100 segundos en tener activos los 10 hilos; esto es, arrancará uno cada 10 segundos.&nbsp; Como pista general, y traduciendo del manual de JMeter:&nbsp;</p> <p> "<em>El periodo de subida debe ser suficientemente grande para evitar una carga excesiva en el inicio de la prueba, y lo suficientemente corto para que los últimos hilos arranquen antes de que los primeros terminen (a no ser que sea eso precisamente lo que se busca)</em>"</p> <p> El contador del bucle representa el número de veces que cada hilo ejecutará la prueba.</p> <p> También se pueden ejecutar los Grupos de Hilos <strong>en diferido</strong> con el Planificador (<em>Scheduler</em>). Esto es muy útil, por ejemplo, si tenemos un Plan de Pruebas con un grupo de hilos en ejecución continua (los usuarios públicos que visitan la web) y otro grupo que representa, por ejemplo, los momentos de mayor uso por parte de los usuarios internos, y que arrancamos de forma independiente al primero.</p> <h2> <a id="petweb">Configurar el Plan para las peticiones web</a></h2> <p> Los elementos que se ejecutan al arrancar un plan de pruebas son los denominados <strong>Controladores</strong> (<em>Controllers</em>). Los más importantes son los&nbsp; Muestreadores (<em>Sampler</em>): Para peticiones FTP, HTTP, JDBC, LDAP,&nbsp; Objetos Java y servicios web y otros. Son los que indican a JMeter qué enviar al servidor, y mediante qué protocolo hacerlo</p> <p> Como podeis suponer, nos centramos en los elementos de Plan de Pruebas referentes a HTTP. Además de los controladores, para el estrés web necesitaremos algún elemento de configuración y algún listener. Como mínimo, <strong>para casi cualquier aplicación web, necesitaremos</strong>:</p> <ul> <li> <u>Un conjunto de samplers HTTP</u>: las peticiones a enviar al servidor. Más adelante aprenderemos a obtenerlas de forma sencilla</li> <li> <u>Un Gestor de Cookies HTTP</u>: Es un 'Elemento de Configuración' que permite que cada hilo (usuario) tenga acceso a las cookies enviadas por el servidor. Es la manera de que el Plan de Pruebas pueda mantener el estado de la aplicación&nbsp; web (la sesión HTTP).</li> <li> <u>Uno o varios Listener</u> que muestren los datos estadísticos recogidos.</li> </ul> <p> Con todo lo dicho, añadimos a nuestro Plan de Pruebas un Gestor de Cookies (<em>botón secundario sobre el Grupo de hilos--&gt; Añadir Elemento de Configuración --&gt; Gestor de Cookies HTTP </em>), y un 'Escritor de datos simple' (<em>botón secundario sobre el Grupo de hilos--&gt; Añadir Listener --&gt; Escritor de datos simple</em>):</p> <p>  </p> <p style="text-align: center;"> <img alt="Plan de Pruebas con Gestor de Cookies y Listener" src="http://rafaeska.es/image/image_gallery?uuid=42438a83-9909-4477-814b-d4bee5899756&amp;groupId=11369&amp;t=1288115458486" style="width: 95%;" /></p> <div class="portlet-msg-info"> <span style="font-size: 12px;"><u>Notas de la GUI:</u> Los cambios que hacemos en la parte derecha del panel se guardan automáticamente en el Plan de Pruebas. Pero aparte de ello es conveniente guardar el Plan de Pruebas al completo (en un fichero .jmx), cosa que puede hacerse con el menu contextual (botón secundario) sobre el nodo del Plan de pruebas en el árbol de la izquierda.</span></div> <h3> <a id="list">Configuración del <strong><em>Listener</em></strong></a></h3> <p> El <em>Listener</em> es el que recoge los datos de tiempo de respuesta, número de errores y otros datos estadísticos de la ejecución de un Plan de Pruebas. Existen muchos tipos distintos. En el manual de JMeter nos avisan de que <strong>todos los <em>listener</em> guardan los mismos datos, pero los visualizan de forma distinta</strong>.</p> <p> Los datos que recogen los listeners, y el formato en el que lo recogen, es común a los diferentes tipos de Listener. Normalmente sólo es necesario añadir uno para recoger los datos, pero pueden añadirse más de uno que recoja los datos de distinta forma, aunque sean siempre los mismos. Por ello es conveniente configurarlos para atender a las necesidades de nuestra Prueba: si tenemos muchas muestras de petición HTTP necesitamos adelgazar al máximo el fichero de resultados. Primero estableceremos un fichero de destino para los resultados, desde el botón 'Navegar' (ver captura anterior): los formatos son .jtl (XML propio de JMeter) y CSV.</p> <div class="portlet-msg-info"> <u>Notas de la GUI</u>: Al poner un nombre de fichero JMeter os mostrará un mensaje de error avisando de que no ha podido cargar el archivo. No pasa nada: en cuanto tenga que escribir datos (durante la ejecución de Text) JMeter creará el fichero.</div> <p> Tras tener el fichero de destino desde el botón 'Configurar' del Listener (ver captura anterior) accedemos a las <strong>propiedades del Listener:</strong></p> <p style="text-align: center;"> <img alt="Opciones de configuración de un Listener" src="http://rafaeska.es/image/image_gallery?uuid=050a5df7-b01b-428f-b874-5081772e7201&amp;groupId=11369&amp;t=1288116915681" style="width: 95%;" /></p> <div class="portlet-msg-alert"> Existen parámetros que sólo se aplican si guardamos los resultados en formato XML, no CSV (esta información se ha perdido en la traducción al español de JMeter. Si elegís el idioma inglés en este diálogo aparece entre paréntesis si el parámetro afecta sólo a CSV o a XML). Tened en cuenta que en formato CSV no se pueden almacenar nada que lleve saltos de línea. Los datos de respuesta de la web&nbsp; (<strong><em>Save Response Data</em></strong>), por ejemplo, no pueden ser guardados en CSV</div> <p> Algunos de estos parámetros tienen mucha<strong> influencia en</strong> el tamaño d<strong>el fichero de resultados que obtendremos</strong>; para empezar <strong>si es XML o no</strong>: guardado en un formato estilo <a href="http://es.wikipedia.org/wiki/CSV" target="_blank">CSV</a> el fichero se reduce bastante.&nbsp; Dependiendo de los objetivos de nuestro Plan de Pruebas, nos interesará recoger cosas distintas. A lo largo de muy distintas pruebas yo lo que he encontrado siempre útil es <strong>utilizar un 'Escritor de Datos Simple' desactivando el uso de XML</strong>. Los ficheros generados pueden ser abiertos luego desde distintos Listener para visualizar un mismo conjunto de estadísticas de distinta forma. Pero si queremos observar los datos que ha devuelto el servidor (y no sólo sus códigos de éxito o error) necesitamos el formato XML.</p> <h2> <a id="proxy">Recogiendo los <em>samplers</em> HTTP: el proxy de JMeter y nuestro navegador</a></h2> <p> Tenemos los usuarios, tenemos configurados los datos a recoger y donde. Nos falta los más importante: las peticiones para el servidor. Los controladores de Petición HTTP pueden añadirse uno a uno, pero es muy tedioso cuando queremos capturar, por ejemplo, diez minutos de uso de la aplicación web que generen 200 peticiones HTTP. Para ello JMeter cuenta con un elemento que mediante un<strong> patrón Proxy puede capturar el tráfico entre un navegador y el servidor</strong> web. <em>Sobre Banco de Trabajo --&gt; botón secundario --&gt; Añadir --&gt; Elementos NoDeprueba --&gt; Servidor Proxy HTTP</em></p> <p>  </p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=c5394d41-80ef-4357-ae09-97eced728573&amp;groupId=11369&amp;t=1288200529898" style="width: 95%;" /></p> <p> La idea consiste en que <strong>configuraremos un navegador para que use de proxy la dirección del proxy de JMeter</strong>: <code>[nombre-maquina]:8080</code>. (Es preferible usar el nombre de máquina en lugar de 'localhost' dado que no siempre los navegadores dejan usar la dirección de <em>loopback</em> como proxy).</p> <div class="portlet-msg-alert"> No os olvideis de arrancar y parar el proxy cuando cambiemos algo en su configuración. ¡¡Y las preferencias del navegador para que use a JMeter de proxy!!</div> <p> De la <strong>configuración del proxy</strong> destacamos dos cosas: el <strong>puerto</strong> (8080 por defecto) y la <strong>agrupación </strong>de los datos de la muestra: Controlador Objetivo y Agrupación. Ambos valores se refieren a cómo se van a agrupar las muestras (las peticiones HTTP) en el árbol del plan de pruebas. A mi siempre me ha sido útil seleccionar en el desplegable de 'Agrupación' la opción '<strong>Poner cada grupo en un nuevo controlador</strong>': esta forma de agrupar peticiones, <strong>intenta organizar el conjunto de muestras distinguiendo entre los distintos 'clicks' en el navegador</strong>; como se puede suponer la distinción entre un click y otro la hace simplemente por el tiempo transcurrido entre una petición y otra. Las aplicaciones asíncronas (AJAX) registrarán las peticiones de forma asíncrona; pero eso no debe ser problema: la asincronía de peticiones no debe dar problemas si nuestra aplicación se comunica así con el servidor.</p> <p> Esto he capturado con las opciones por defecto del proxy:</p> <p>  </p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=3d742583-efca-4ce7-a0c7-9cb804a5d76b&amp;groupId=11369&amp;t=1288202658815" style="width: 60%;" /></p> <p> Las peticiones han sido :</p> <ul> <li> Raíz de la web http://rafaeska.es</li> <li> Click en sección 'Algo que añadir'</li> <li> Click en sección 'Android'</li> </ul> <p> Como veis, se han creado varios controladores HTTP, unos para direcciones dinámicas y otros para direcciones estáticas.</p> <p> Ahora vamos a establecer alguna <strong>agrupación para las peticiones</strong> para que queden más legibles y para poder identificar los distintos 'clicks' del usuario: en el combo de 'Agrupación' dentro de la configuración del proxy de JMeter seleccionamos 'Poner cada grupo en un nuevo controlador'. Borro las peticiones registradas hasta ahora (sobre los nodos del árbol) y reinicio el proxy de JMeter.</p> <p> Ahora una navegación idéntica a la anterior queda agrupada así:</p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=ad54f849-07be-4ba0-aaf0-4cf809cd6016&amp;groupId=11369&amp;t=1288205669063" style="width: 75%;" /></p> <h3>  </h3> <h3> <a id="filtrar">Filtrar las peticiones recogidas</a></h3> <p> Dependiendo de los objetivos de nuestra Prueba es habitual necesitar<strong> no incluir en nuestras peticiones ciertos recursos</strong> que el navegador solicita al servidor. Por ejemplo, si nuestra intención es comprobar el comportamiento de una aplicación web con altas cargas de trabajo o mucha cantidad de datos es posible que lo que nos interese son las peticiones dinámicas, las que generan carga de proceso. Esto es habitual cuando probamos en entornos de pruebas, con capacidades de ancho de banda menores que los de los entornos donde finálmente se desplegará la aplicación.</p> <p> Por otra parte, si queremos tiempos de respuesta más fieles al entorno real, no deberíamos filtrar ninguna petición.</p> <p> En cualquier caso, <strong>desde la configuración del Proxy HTTP, podemos elegir qué peticiones registrar y cuales no</strong> basándonos en las URLs y ayudándonos de las <a target="_blank">bénditas/malditas</a> <a target="_blank">expresiones regulares</a>.</p> <p> En mi caso no me interesa incluir las peticiones a imágenes. En el campo <em>'URL Patrones a excluir</em>'&nbsp; de la configuración del Proxy HTTP pongo</p> <pre style="text-align: center;"> .*\.png .*\.ico </pre> <p> Con ello, evito PNGs e ICOs. La misma recogida de peticiones anterior ahora queda así:</p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=7077ed37-3bb1-4204-94e2-46bb10644d03&amp;groupId=11369&amp;t=1288344235745" style="width: 80%;" /></p> <p> Con las peticiones agrupadas en tres controladores (los 3 clicks del usuario) y sin imágenes PNG ni ICO.</p> <p>  </p> <h2> <a id="ejec">Ejecución del Test</a></h2> <p> Nuestro Plan de Pruebas ya está preparado. Mi árbol muestra este aspecto:</p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=45afc87b-a1d3-4e4c-824d-7222b982fb9d&amp;groupId=11369&amp;t=1288344759266" style="width: 75%;" /></p> <p> <br /> La ejecución de la prueba se arranca desde el menú 'Lanzar' y la única indicación de que se está ejecutando es un pequeño cuadradito en verde en la esquina superior derecha de la interfaz</p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=4b087bb6-e54a-4ebd-a930-9c238c65866f&amp;groupId=11369&amp;t=1288345591324" style="width: 10%; height: 10%;" /></p> <p> Cuando se apaga este piloto verde, la prueba ha terminado</p> <div class="portlet-msg-info"> Nota de la GUI: El pequeño piloto verde tiene a su lado izquierdo el número de hilos en ejecución sobre el total de hilos (2 de un total de 10)</div> <h2> <a id="result">Leer los resultados del test de JMeter</a></h2> <p> Es el momento de hacer lo más difícil: interpretar los resultados. Con los diferentes <em>listener</em> puedo leer un mismo conjunto de datos. Vamos a añadirlos ahora al Plan de Pruebas, con el único fin de abrir el fichero de resultados y visualizar los resultados de diferentes maneras</p> <h3> <a id="summ">'Summary Report' e 'Informe Agregado'</a></h3> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=1e686df7-386b-4c45-bff4-2603a1474e4a&amp;groupId=11369&amp;t=1288346847637" style="width: 95%;" /></p> <p> La única diferencia entre ambos es que el Informe Agregado calcula el <a href="http://es.wikipedia.org/wiki/Percentil#Percentiles" target="_blank">Percentil</a> 90 de la muestra y el Summary Report no. Es más ligero en memoria el último, así que <strong>usad preferentemente el 'Summary Report'</strong>.</p> <p> ¿Qué significan sus campos?</p> <p> Tenemos una tabla con <strong>una fila para cada petición realizada</strong>. Observad que las peticiones a '/combo' se han repetido 30 veces (columna Muestras): esto es porque existían 3 muestras de peticiones a esa URL en diferentes momentos de la Prueba. Aquí salen agrupadas.</p> <p> Los valores están calculados tomando el tiempo total que ha tardado la prueba (la ejecución de mis 10 usuarios), por lo tanto, cuanto más muestras haya más tiempo total de ejecución; influye en cada línea de la tabla. Para cada línea (petición) tenemos&nbsp;</p> <ul> <li> el <u>máximo</u> de tiempo invertido por una petición (columna Max).</li> <li> el <u>mínimo</u> de tiempo invertido por una petición (columna Min).</li> <li> la <u>media</u> de tiempo invertido por una petición (columna Media).</li> <li> la <u>mediana</u> de tiempo invertido por una petición: significa que el 50% de las muestras tardaron menos del valor reflejado.</li> <li> El tanto por ciento de <u>respuestas con error</u>.</li> <li> El <u>rendimiento</u> (<em>thoughput</em>): número de peticiones procesadas en una unidad de tiempo, que puede ser segundos, minutos y horas.</li> <li> El rendimiento en<u> Kb/segundo</u>: igual que la anterior pero con cantidad de datos en lugar de peticiones</li> </ul> <p> Podemos decir, por ejemplo, que el servidor es capaz de responder a 1,6 peticiones por segundo a la página raíz de la web (primera muestra), o que la petición a '/html/portlet/blogs/css/main.jsp' &nbsp; es la que más tarda en procesarse de media.</p> <p> Una versión extendida del 'Informe Agregado' es el '<strong>Aggregate Graph</strong>', que muestra los mismos datos que aquel, pero permitiendo generar gráficos de barras de las diferentes columnas (media, máximo, mínimo...). Los gráficos se pueden guardar, para incluir en el bonito informe para el jefe. Observad que he necesitado aumentar el 'Height' por defecto del gráfico:</p> <p> (Pulsar para ampliar)</p> <p> <a href="http://rafaeska.es/image/image_gallery?uuid=eb68caeb-1fc0-4010-beee-f7b9dd7eb17f&amp;groupId=11369&amp;t=1288612498760" target="_blank"><img alt="" src="http://rafaeska.es/image/image_gallery?uuid=774771ac-6ea2-4ac8-b35e-374484145c83&amp;groupId=11369&amp;t=1288612508576" style="width: 95%;" /></a></p> <p> Para estos mismos datos existen otros listeners para visualizar los resultados en gráficos de distintos tipos, como el '<strong>Gráfico de Resultados</strong>' que muestra en un sólo gráfico los valores estadísticos recogidos relacionados con el número de muestras: cuanto mayor sea el número de muestras (peticiones) más representativos serán los datos de este gráfico.</p> <h3> <a id="arbol">Árbol de Resultados</a></h3> <p> Es un listener muy útil, sobre todo cuando nuestro objetivo principal es comprobar el funcionamiento de una aplicación concreta, más que toda una infraestructura web.</p> <p> El&nbsp; '<strong>Árbol de Resultados</strong>'&nbsp; permite visualizar los datos de petición y respuesta de <strong>cada una de las muestras</strong> individuales (140 en total, en nuestro ejemplo). Es muy utilizado cuando estamos depurando el comportamiento de la Prueba : ¿Por qué no se dan de alta los datos en la base de datos? ¿Por qué la petición que sé que tarda más me responde tan rápido en la Prueba?. A primera vista parece que la respuesta más habitual a estas preguntas está en que hay mensajes de error (los entrañables HTTP 50x) en las respuestas del servidor.&nbsp; Pero para depurar esto <strong>lo que necesito es ver qué errores se han producido, porqué se han producido y con qué peticiones</strong>.</p> <p> Como avisé antes, para esto necesitaremos que nuestro Listener (nos sirve el Escritor de Datos Simple) <strong>guarde las respuestas </strong>del servidor, y para poder hacer esto, <strong>tiene que almacenarse en formato XML y seleccionar las opciones de configuración adecuadas</strong>.</p> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=d850ea30-d683-4729-9e95-b04160069094&amp;groupId=11369&amp;t=1288695739113" style="width: 75%;" /></p> <p> Es conveniente, para la depuración del funcionamiento de la Prueba, y para depurar el funcionamiento de una aplicación web, conservar las cabeceras de respuesta HTTP.</p> <p> Al configurar en mi Prueba el listener de esta forma, mis tres insignificantes clicks con 10 usuarios han generado un fichero de resultados de 5,6 MB, por lo que usad con <strong>cuidado con el fichero de resultados en esta recogida de datos</strong>.</p> <p> El Árbol de resultados permite <strong>previsualizar la respuesta del servidor</strong>, formateandola de diferentes formas: XML, HTML y JSON las más relevantes. Además podemos buscar literales y Expresiones Regulares en la respuesta:</p> <p style="text-align: center;"> (Pulsar para ampliar)<a href="http://rafaeska.es/image/image_gallery?uuid=c708b3dc-36ac-40cc-af6e-22b30e2083c9&amp;groupId=11369&amp;t=1288698327227" target="_blank"><img alt="" src="http://rafaeska.es/image/image_gallery?uuid=e28f6d62-7550-4bbf-b2b1-624d8e1ec4ff&amp;groupId=11369&amp;t=1288698313334" style="width: 95%;" /></a></p> <h2> <a id="resumen">Resumen</a></h2> <p> Hemos configurado un Plan de Pruebas con los usuarios de la prueba, el Listener para recoger los datos, y las peticiones generadas por nuestro navegador contra el Proxy HTTP de JMeter. Hemos ejecutado la prueba y hemos observado sus resultados con diferentes visualizadores (Listerner).</p> <p> Tenemos un punto de partida básico para empezar a hacer pruebas, y una pequeña experiencia con JMeter que nos va a servir para el próximo artículo. Unas Buenas Prácticas para estrés web con JMeter.</p> <p> Espero que os sirva de algo</p> Rafa Eska 2010-10-26T10:12:46Z Publicada TuNombreEgipcio en el Android Market Rafa Eska http://rafaeska.es/algo-que-anadir/-/blogs/publicada-tunombreegipcio-en-el-android-market 2010-09-15T11:14:20Z 2010-08-30T09:17:07Z <p> Desde hace un par de días, está disponible <a href="http://rafaeska.es/es/escriba-digital-nombres-egipcios-android">TuNombreEgipcio</a> en el Android Market. Si quereis hacer algún comentario sobre esta aplicación para Android, este es el lugar. Espero que lo disfruteis.</p> <p> <strong>Edito</strong>: He subido la versión 2: correcciones menores (se oculta el teclado, algún aviso nuevo) y limitación a 15 letras</p> <p> <strong>Edito II:</strong> Versión 3: localización al francés (gracias a <a href="http://www.android-software.fr" target="_blank">Laurent</a> ) y corrección de bug de nombres sólo con cifras</p> <p> From two days ago, you can download <a href="http://rafaeska.es/es/escriba-digital-nombres-egipcios-android">YourEgyptianNoun</a> from Android Market. If you also want to tell something to the developer (me) his is the place. I hope you enjoy it.</p> <p> <strong>Edit</strong>: I have uploaded version 2: lesser corrections (hiding keyboard, some advice to user) and 15 letters limitation</p> <p> <strong>Edit II</strong>: Version 3: Frech Locate (thanks to <a href="http://www.android-software.fr" target="_blank">Laurent</a>) and minor bug</p> Rafa Eska 2010-08-30T09:17:07Z Configurar los fuentes de Liferay 6.0.5 para compilar con Eclipse 3.5.2 (Galileo) Rafa Eska http://rafaeska.es/algo-que-anadir/-/blogs/configurar-los-fuentes-de-liferay-6-0-5-para-compilar-con-eclipse-3-5-2-galileo 2010-08-29T19:57:38Z 2010-08-22T09:31:31Z <p> Para meter mano en los fuentes de Liferay (¿Por qué <a href="http://www.liferay.com/es/community/wiki/-/wiki/Proposals/Web+Content+Improvments;jsessionid=50E24468B0DFDA3C729185483C20A8F1.node-1#_36_message_4045147" target="_blank">no admite comentarios anónimos en el contenido web</a>?) he necesitado instalarlo en Eclipse, para poder husmear en&nbsp; el código a gusto. Los pasos que he seguido han sido:</p> <ul> <li> <strong>Descargar los fuentes</strong> del último lanzamiento estable de la <a href="http://www.liferay.com/products/liferay-portal/download/ce-vs-ee" target="_blank">página de Liferay</a>.</li> <li> <strong>Crear</strong> un directorio que será el <strong>espacio de trabajo</strong> (<em>workspace</em>) de Eclipse para Liferay, <strong>descomprimir</strong> en él el fichero de los fuentes, y <strong>renombrar</strong> el dirtectorio descomprimido a 'Liferay'.</li> <li> Abrir Eclipse, indicándole el nuevo espacio de trabajo al directorio creado</li> <li> Desde el menú Archivo, <strong>importar el proyecto</strong> eligiendo el el árbol 'Proyecto existente en el espacio de trabajo' (<em>Existing projects into workspace</em>). Al seleccionar la carpeta 'Liferay' dentro de nuestro workspace, Eclipse importará el Proyecto e intentará compilarlo.</li> </ul> <p style="text-align: center;"> <a href="http://rafaeska.es/image/image_gallery?uuid=a9c4c106-71f7-4733-bc17-8bbed90d004a&amp;groupId=11369&amp;t=1282472251888" target="_blank"><img alt="Importación del proyecto a Eclipse" src="http://rafaeska.es/image/image_gallery?uuid=0c5e8912-a3af-4cfa-9caf-bb282ecfd650&amp;groupId=11369&amp;t=1282472263293" style="width: 50%; height: 50%;" /></a></p> <p>  </p> <p>  </p> <ul> <li> Que no haya sustos. Parece que hay <strong>dependencias</strong> para compilar que no están incluidas (¿o estoy haciendo algo mal? ) A mi me ha sido necesario añadir al '<em>Build Path</em>' <ul> <li> El <em>jar</em> de <a href="http://maven.apache.org/" target="_blank"><strong>Maven</strong></a>. Que está en el directorio 'lib' de <a href="http://maven.apache.org/download.html" target="_blank">su distribución binaria</a></li> <li> El <em>jar</em> de un par de paquetes de <strong><a href="http://plexus.codehaus.org/" target="_blank">Plexus</a></strong>. Los he sacado de <a href="http://repository.codehaus.org/org/codehaus/plexus/plexus-archiver/1.0-alpha-11/plexus-archiver-1.0-alpha-11.jar">aquí</a> y de <a href="http://repository.codehaus.org/org/codehaus/plexus/plexus-io/1.0-alpha-3/plexus-io-1.0-alpha-3.jar">aquí</a>.</li> </ul> He copiado estas 3 bibliotecas al directorio <code>$WORKSPACE/Liferay/lib/development</code> , y los he añadido al '<em>Build Path</em>' del proyecto en Eclipse</li> <li> Parece que las dependencias están satisfechas, pero todavía tengo 39 errores de compilación. Para quitarlos: <ul> <li> <strong>Borrad</strong> el fichero <strong>jndi.jar</strong> de ,<code>$WORKSPACE/Liferay/lib/development</code> como cuentan <a href="http://www.liferay.com/community/forums/-/message_boards/message/3586762#_19_message_3613266" target="_blank">aquí.</a>. De 39 errores de compilación pasamos a 6</li> <li> <p> Ahora hay que organizar el orden de compilación, para que Eclipse tenga preferencia en la compilación por las clases del SDK de Java. Para ello 'Configure Build Path' --&gt; Pestaña 'Order and Export' y colocamos la 'JRE System Library' (java6-openjdk en mi caso) justo antes de los jar incluidos en <code>$WORKSPACE/Liferay/lib/development </code> como se ve en esta captura:</p> </li> </ul> </li> </ul> <p style="text-align: center;"> <img alt="" src="http://rafaeska.es/image/image_gallery?uuid=783f0f96-1a0c-4f03-8dd2-547bc735498c&amp;groupId=11369&amp;t=1282475934617" style="width: 50%; height: 50%;" /></p> <p> Ya está compilado. ¡Ojo! No he intentado arrancarlo (falta configurar el Servidor de Aplicaciones y la Base de Datos, como poco). Pero para mis necesidades, ¡voy sobrado!</p> <p> Espero que os sirva de algo</p> Rafa Eska 2010-08-22T09:31:31Z ¿ Quién desarrolla el kernel de Linux ? (Traducción) Rafa Eska http://rafaeska.es/algo-que-anadir/-/blogs/¿-quien-desarrolla-el-kernel-de-linux-traduccion 2010-08-19T17:56:20Z 2010-08-19T08:10:06Z <p> Dejo aquí un artículo que hace un tiempo traduje, de la <a href="http://www.linuxfoundation.org/">Linux Foundation</a>, que habla sobre cómo funciona y a qué ritmo evoluciona el desarrollo del núcleo de Linux. Es de Abril del 2008, pero ilustra bastante bien la enorme velocidad que puede alcanzar el desarrollo de un proyecto de Software Libre de tamaña envergadura. Desde el punto de vista de la Ingeniería del Software resulta sorprendente los buenos resultados que se alcanzan en el kernel. Aquí viene la traducción de <a href="http://www.linux.com/index.php?option=com_rubberdoc&amp;view=doc&amp;id=14&amp;format=raw" target="_blank">éste original</a></p> <p> <span class="Apple-style-span" style="line-height: 27px; font-size: 20px; font-weight: bold;">Desarrollo del Núcleo de Linux (Abril 2008)</span></p> <p style="margin-top: 0.42cm; page-break-after: avoid;"> <font face="Nimbus Sans L, sans-serif"><font size="4">Cómo va de rápido, quién lo está haciendo, qué están haciendo, y quien lo patrocina</font></font></p> <p> Por <a href="http://www.kroah.com/" target="_blank">Greg Kroah-Hartman, SuSE Labs / Novell Inc.</a>, <script></script><a href="http://www.lwn.net/" target="_blank"><br /> Jonathan Corbet, LWN.net</a>, <script></script><a href="http://www.linux-foundation.org/weblogs/amanda/" target="_blank"><br /> Amanda McPherson, The Linux Foundation</a>, <script></script></p> <p> <em><font color="#003e69"><i>Traducido por Rafael Ruiz </i></font></em><em><font color="#003e69"><span style="font-style: normal;">. </span></font></em><em><font color="#003e69"><i>Esta traducción es de dominio público. El artículo original tiene unos términos de uso <a href="http://creativecommons.org/licenses/by/3.0/">CC-A 3</a></i></font></em></p> <p> <em><font color="#008000">El núcleo, que forma el corazón de los sistemas Linux, es el resultado del proyecto de software colaborativo más grande jamás emprendido. Distribuciones regulares cada 2 o 3 meses hacen entrega de actulizaciones estables a los usuarios de Linux, todas ellas con características significativas nuevas, soporte a nuevos dispositivos, y rendimiento mejorado. La tasa de cambio en el kernel es alta, y en crecimiento, con casi 10.000 parches añadidos a las recientes distribuciones del kernel. Cada una de estas versiones contiene el trabajo de casi 1.000 desarrolladores representados en cerca de 100 empresas.</font></em></p> <p> <em><font color="#008000">Desde 2005, unos 3.700 desarrolladores individuales de unas 200 empresas han contribuido al kernel. Así, el kernel de Linux se ha convertido en un recurso común desarrollado a escala masiva por empresas que son feroces competidoras en otros terrenos.</font></em></p> <h2 class="western"> &nbsp;<font color="#000000">Introducción </font></h2> <p> El núcleo de Linux es el software de más bajo nivel ejecutándose en un sistema Linux. Se encarga de manejar el software, ejecutar los programas de los usuarios y de mantener la seguridad general y la integridad del sistema entero. Es este núcleo, el que, tras su lanzamiento inicial en 1991 por Linus Torvalds, catapultó el desarrollo de Linux como un todo. El núcleo es una parte relativamente pequeña en un sistema Linux completo (muchos otros grandes componentes vienen del proyecto GNU, de los proyectos GNOME y KDE, el proyecto X.org y otras fuentes ), pero es el corazón que determina cómo de bien funcionará el sistema, y es el fragmento que es realmente único en Linux</p> <p> El núcleo de Linux es un proyecto interesante de estudiar por un buen número de razones. Es uno de los más grandes componentes de prácticamente cualquier sistema Linux. Tiene como característica uno de los procesos de desarrollo más veloces e involucra a más programadores que cualquier otro proyecto de software libre. Este artículo examina cómo funciona ese proceso, centrándose en los tres últimos años de la historia del kernel, representados en los lanzamientos de las versiones 2.6.11 a 2.6.24.</p> <div dir="LTR" id="Sección1"> <h2 class="western"> <font color="#000000">Modelo de desarrollo</font></h2> <p> Con la serie 2.6.x, el kernel ha cambiado a un modelo relativamente estricto basado en distribuciones periódicas. En la 'Cumbre de Desarrolladores del Kernel' en Ottawa, Canada, 2005, se decidió que los lanzamientos de versiones del kernel se harían cada 2-3 meses, siendo cada una, una distribución 'mayor' en la que se incluyen nuevas características y cambios internos en el API.</p> <p> Este ciclo tan rápido de distribuciones se eligió como medio de tener nuevas características para los usuarios de una manera estable, con un retardo mínimo. El resultado es que el nuevo código – características, drivers de dispositivos, etc – está disponible en un kernel estable a los pocos meses de su terminación, minimizando o eliminando la necesidad de los distribuidores de portar código en desarrollo a distribuciones estables. De esta forma los kernels lanzados por los distribuidores contienen menos cambios 'específicos-de-la-distribución', derivando en una mayor estabilidad y menores diferencias entre distribuciones.</p> <p> Cada lanzamiento de la rama 2.6.x es una versión estable, que se hace disponible cuando la lista de bugs grandes se ha hecho tan pequeña como sea posible. Para problemas que aparecen después de la distribución de la versión, existe la rama (branch) “-stable” como forma de liberar correciones rapidamente a la comunidad. Esto se entiende mejor con el diagrama de la Figura 1.</p> </div> <p> <img alt="Figura 1: Ciclo de lanzamientos del Núcleo Linux" src="http://rafaeska.es/image/image_gallery?uuid=255bd41a-86f0-47ea-8729-53068cf8d660&amp;groupId=11369&amp;t=1282208511344" style="width: 250px; height: 423px;" /></p> <p> <em><font color="#000000">Figura 1 – Ciclo de Distribución del Kernel Linux</font></em></p> <p> <font color="#000000">El equipo del kernel liberó el 2.6.19 como una 'versión estable'. Los desarrolladores entonces empezaron a trabajar en nuevas funcionalidades, y empezaron a liberar versiones 'Release Candidate' como kernels en desarrollo para que la gente pudiera ayudar en las pruebas y depurar los cambios. Cuando todos estuvieron de acuerdo en que la versión de desarrollo era suficientemente estable, se liberó como el kernel 2.6.20</font></p> <p> <font color="#000000">Mientras se desarrollaban nuevas funcionalidades, se iban distribuyendo las versiones 2.6.19.1, 2.6.19.2 y otras, conteniendo actualizaciones de seguridad y correción de fallos.</font></p> <p> <font color="#000000">Este artículo se centra exclusivamente en las principales distribuciones 2.6.x, excluyendo las actualizaciones de “-stable”. Éstas son pequeñas actualizaciones y, en algún caso, el diseño del proceso de desarrollo exije que cambios aceptados para -stable tengan que ser aceptados también en la línea principal para la siguiente versión mayor.</font></p> <p> <span class="Apple-style-span" style="line-height: 24px; font-size: 18px; font-weight: bold;">Frecuencia de lanzamiento de versiones</span></p> <p> <font color="#000000">Cuando en un principio los desarrolladores del kernel decidieron adoptar este nuevo ciclo de desarrollo, se dijo que se liberaría un nuevo kernel cada 2-3 meses, para no tener que 'portar hacia atrás' nuevos desarrollos. En la Tabla 1 se pueden ver los días transcurridos entre cada distribución:</font></p> <p> <font color="#000000"><img align="BOTTOM" alt="Figura 1 Frecuencias de lanzamiento del Núcleo" name="gráficos2" src="http://rafaeska.es/image/image_gallery?uuid=c27ab913-a9aa-4ca6-b194-f45f259d7fdf&amp;groupId=11369&amp;t=1282208807586" style="border-width: 0px; border-style: solid; width: 423px; height: 352px;" /> </font></p> <p> <em><font color="#000000">Tabla 1 – Frecuencia de distribuciones del kernel.</font></em></p> <p> <font color="#000000">Resulta que tenían razón, con una media de 2,7 meses entre versiones</font></p> <p> <span class="Apple-style-span" style="line-height: 24px; font-size: 18px; font-weight: bold;">Índice de Cambio</span></p> <p> <font color="#000000">Cuando se prepara un trabajo para enviarlo al kernel, los desarrolladores dividen sus cambios en pequeñas unidades individuales llamadas 'parches'. Estos parches normalmente hacen solo una cosa en el fuente; se construyen uno sobre otro, modificando el código añadiendo, cambiando o quitando líneas. Cada parche debería, al ser aplicado, conducir a un kernel que aún compila y funciona adecuadamente.</font></p> <p> <font color="#000000">Esta disciplina fuerza a los desarrolladores del núcleo a dividir sus cambios en pequeñas piezas lógicas; como resultado, cada cambio puede ser revisado para la corrección y calidad del código. Otro resultado es que el número de cambios individuales que se incluyen en cada versión del kernel es muy grande, como observamos en la Figura 2:</font></p> <p> <font color="#000000"><img align="BOTTOM" alt="Cambios realizados por lanzamiento de nueva versión" name="gráficos3" src="http://rafaeska.es/image/image_gallery?uuid=1bfd1889-ed4a-4b80-9122-6574689e3a47&amp;groupId=11369&amp;t=1282211052073" style="border-width: 0px; border-style: solid;" /></font></p> <p> <em><font color="#000000">Figura 2 – Cambios por versión del kernel.</font></em></p> <p> <font color="#000000">Tomando en cuenta la cantidad de tiempo necesario para cada versión del kernel, uno puede llegar al número de cambios aceptados en el kernel por hora. Se pueden ver los resultados en la Figura 3:</font></p> <p> <font color="#000000"><img align="BOTTOM" name="gráficos4" src="http://rafaeska.es/image/image_gallery?uuid=53b7857a-d7d1-4994-8765-026b5f88859d&amp;groupId=11369&amp;t=1282211052074" style="border-width: 0px; border-style: solid; width: 524px; height: 370px;" /></font></p> <p> <em><font color="#000000">Figura 3 – Cambios por hora en cada versión del kernel.</font></em></p> <p> <font color="#000000">Así, desde la versión 2.6.11 a la 2.6.24 (un total de 1140 días), ha habido, de media, 2,83 parches aplicados al kernel, tres por hora. Y estos son sólo los que fueron aceptados. La habilidad de mantener esta tasa de cambios durante años no tiene precedente en ningún proyecto público de software.</font></p> <h2 class="western"> <font color="#000000">Tamaño de los fuentes del Kernel </font></h2> <p> <font color="#000000">El kernel de Linux ha ido creciendo en tamaño a lo largo del tiempo en la medida en que se añadía soporte a más hardware y nuevas características.. Para los números que siguen hemos contado todo lo que se incluía en cada versión como 'código fuente', incluso a pesar de que u8n pequeño porcentaje del total son los scripts usados para configurar y compilar el kernel, así como una pequeña cantidad de documentación. Estos ficheros, también son parte del trabajo mayor, y también merecen ser cuantificados.</font></p> <p> <font color="#000000">La información de la figura 4 muestra el número de ficheros y líneas en cada versión del kernel:</font></p> <p> <font color="#000000"><img align="BOTTOM" name="gráficos5" src="http://rafaeska.es/image/image_gallery?uuid=dab5bb57-0713-45ec-8b56-64bee5aaa15f&amp;groupId=11369&amp;t=1282211052075" style="border-width: 0px; border-style: solid;" /></font></p> <p> <em><font color="#000000">Figura 4 – Tamaño por versión del kernel</font></em></p> <p> <font color="#000000">A lo largo de las diferentes versiones, el equipo del kernel ha tenido una tasa de crecimiento del 10 por ciento anual, un número impresionante dado el tamaño del árbol del código. Pero el kernel no sólo crece. Con cada cambio que se hace en el árbol del código, se añaden, se modifican y se borran líneas para cumplir con las necesidades de los cambios. Observando estos números, divididos por días, muestra lo rápido que el árbol del código del kernel se desarrolla en el tiempo. Se puede ver esto en la figura 5:</font></p> <p> <font color="#000000"><img align="BOTTOM" name="gráficos6" src="http://rafaeska.es/image/image_gallery?uuid=889c7e6f-0d5b-45c8-a8ae-7d1c0c9afec7&amp;groupId=11369&amp;t=1282211052076" style="border-width: 0px; border-style: solid;" /> </font></p> <p> <em><font color="#000000">Figura 5 – Tasa de cambio por versión del kernel</font></em></p> <p> <font color="#000000">Resumiendo estas cifras se llega al impresionante número de 3.621 líneas añadidas, 1.550 líneas borradas y 1.425 líneas cambiadas cada día en los últimos 2 años y medio. Esta tasa de cambios es más grande que la de cualquier otro proyecto público de software de cualquier tamaño.</font></p> <h2 class="western"> <font color="#000000">Quién hace el trabajo</font></h2> <p> <font color="#000000">El número de diferentes desarrolladores que desarrollan el kernel y las empresas identificables que patrocinan este trabajo se ha ido incrementando a lo largo de las diferentes versiones del kernel, como se puede ver en la tabla 2:</font></p> <p> <font color="#000000"><img align="BOTTOM" name="gráficos7" src="http://rafaeska.es/image/image_gallery?uuid=4e5c4ae0-9f60-47ab-bdce-b65c7ab6a824&amp;groupId=11369&amp;t=1282211052077" style="border-width: 0px; border-style: solid;" /></font></p> <p> <em><font color="#000000">Tabla 2 – Número de desarrolladores individuales y empleadores</font></em></p> <p> <font color="#000000">De hecho, la comunidad de desarrollo individual se ha duplicado en los últimos 3 años.</font></p> <p> <font color="#000000">A pesar del gran número de desarrolladores individuales todavía existe una cantidad relativamente pequeña que hacen la mayoría del trabajo. En los últimos tres años los 10 desarrolladores individuales de la cabeza de la lista han aportado casi el 15 % de los cambio, y los 30 primeros de la lista han aportado el 30 %. La lista de desarrolladores individuales, el número de cambios que han aportado y su porcentaje sobre el total se pueden ver en la Tabla 3:</font></p> <p> <font color="#000000"><img align="BOTTOM" name="gráficos8" src="http://rafaeska.es/image/image_gallery?uuid=8e514c5e-7ecb-4d6f-acff-a944ae8489bb&amp;groupId=11369&amp;t=1282211052078" style="border-width: 0px; border-style: solid; width: 338px; height: 582px;" /></font></p> <p> <em><font color="#000000">Tabla 3 – Contribuciones individuales al kernel.</font></em></p> <h2 class="western"> <font color="#000000">Quién patrocina el trabajo</font></h2> <p> <font color="#000000">El núcleo de Linux es un recurso utilizado por una gran variedad de empresas. Muchas de estas nunca han participado en el desarrollo del kernel; están satisfechos con el software tal cual es y no se sienten en la necesidad de ayudar en la conducción de su desarrollo. Pero, como se ve en la Tabla 4, un número creciente de empresas trabajan en mejoras del kernel.</font></p> <p> <font color="#000000"><img align="BOTTOM" name="gráficos9" src="http://rafaeska.es/image/image_gallery?uuid=e970dfbb-88ef-4da7-ae55-b82649f7575d&amp;groupId=11369&amp;t=1282211052079" style="border-width: 0px; border-style: solid;" /></font></p> <p> <em><font color="#000000">Tabla 4 – Empresas trabajando para la mejora del kernel</font></em></p> <p> <font color="#000000">Arriba nos centramos en empresas que tienen contratados a desarrolladores del kernel. De cada desarrollador, se ha obtenido su filiación corporativa mediante uno de los siguientes medios:</font></p> <ol> <li> <p> <font color="#000000">El uso de direcciones de correo de la empresa.</font></p> </li> <li> <p> <font color="#000000">Información de patrocinio incluida en el código que aportan, o</font></p> </li> <li> <p> <font color="#000000">Mediante consulta directa al desarrollador.</font></p> </li> </ol> <p> <font color="#000000">Los números presentados son necesariamente aproximados; los desarrolladores pueden cambiar de empleo, y pueden hacer trabajo personal, de forma independiente al horario laboral. De todas formas, pueden ser lo suficientemente cercanos a la realidad como para apoyar ciertas conclusiones.</font></p> <p> <font color="#000000">Hay un buen número de desarrolladores para los que no ha sido posible determinar su filiación corporativa; son los que hemos agrupado en 'unknown' en la Tabla 4. Con pocas excepciones, las personas de esta categoría han contribuido con 10 o menos cambios al kernel en los últimos tres años, pero el gran número de estos desarrollos hace que su contribución total sea bastante alta.</font></p> <p> <font color="#000000">La categoría 'None', al contrario, representa a desarrolladores de los que es bien sabido que hacen sus aportaciones por su cuenta, sin contribución financiera de compañía alguna.</font></p> <p> <font color="#000000">Los 10 máximos contribuidores, incluyendo los grupos 'unknown' y 'none' realizan el 75 % del total de las aportaciones. Es de resaltar que, incluso si se asume que todo el grupo 'unknown' trabajaban por su cuenta, alrededor del 70 % de todo el desarrollo del kernel está realizado por desarrolladores pagados por su trabajo.</font></p> <p> <font color="#000000">Lo que vemos aquí es que una pequeña cantidad de empresas es responsable de una gran proporción de cambios en el kernel. Pero también hay una larga lista de “compañías a la cola” que han hecho cambios significativos. No debe de haber otros ejemplos de ningún recurso común tan grande que sea apoyado por un grupo tal de actores independientes de forma tan colaborativa.</font></p> <h2 class="western"> <font color="#000000">Porqué las empresas patrocinan el desarrollo del Kernel.</font></h2> <p> <font color="#000000">La lista de empresas que participan en el desarrollo del núcleo incluye a la mayoría de las más exitosas firmas de tecnología de la actualidad. Ninguna de estas empresas apoyan el desarrollo como acto de caridad; en cada caso, las empresas consideran que mejorar el kernel les ayuda a ser más competitivos en sus mercados. Algunos ejemplos:</font></p> <p style="margin-bottom: 0cm;">  </p> <ul> <li> <p style="margin-bottom: 0cm;"> <font color="#000000">Empresas como IBM, Intel, SGI, MIPS, Freescale, HP, etcétera trabajan para asegurar que Linux corre adecuadamente sobre su hardware, Esto, a cambio, hace sus ofertas más atractivas para los usuarios de Linux, incrementando sus ventas.</font></p> </li> <li> <p style="margin-bottom: 0cm;"> <font color="#000000">Distribuidores como RedHat, Novell y MontaVista tienen un claro interés en hacer de Linux tan capaz como puedas ser. Aunque estas firmas compiten con fuerza contra las otras por la captación de clientes, todas trabajan a la par para hacer de Linux un producto mejor.</font></p> </li> <li> <p style="margin-bottom: 0cm;"> <font color="#000000">Empresas como Sony, Nokia y Samsung distribuyen Linux como componente de sus productos como cámaras de vídeo, equipos de televisión y teléfonos móviles. Contribuyendo en el proceso de desarrollo estas compañías se aseguran de que Linux continuará siendo una base sólida para sus productos en el futuro.</font></p> </li> <li> <p> <font color="#000000">Empresas que no son del negocio de las tecnologías de la información pueden extraer beneficios en trabajar con Linux. El kernel 2.6.25 incluirá una implementación del protocolo de red PF_CAN que ha sido aportado por Volkswagen. PF_CAN permite comunicaciones fiables entre componentes en entornos propensos a interferencias, como los que podemos encontrar en automóviles. Linux dio a Volkswagen una plataforma sobre la que podía construir su código fuente para trabajo en red; después la empresa encontró provechoso aportar ese código para que pudiera ser mantenido con el resto del kernel. </font><a href="http://lwn.net/Articles/253425/">Http://lwn.net/Articles/253425/</a><font color="#000000"> para más información sobre este trabajo.</font></p> </li> </ul> <p> <font color="#000000">Hay un buen número de buenas razones para que las empresas apoyen el núcleo de Linux. Como resultado Linux tiene una amplia base de soporte que no depende de una única compañía. Incluso si el contribuidor más grande cancelase su participación mañana, el kernel de Linux permanecería sobre pies firmes con una comunidad de desarrollo grande y activa.</font></p> <p> <span class="Apple-style-span" style="line-height: 24px; font-size: 18px; font-weight: bold;">Conclusión</span></p> <p> <font color="#000000">El núcleo de Linux es uno de más grandes y exitosos proyectos 'open source' que nunca se han llevado a cabo. La enorme tasa de cambio y el número de los contribuidores individuales muestra que tiene una vibrante y activa comunidad, provocando la constante evolución del kernel en respuesta al número de diferentes entornos en los que se usa. Hay suficientes empresas participando para financiar la enorme cantidad de esfuerzo de desarrollo, incluso si muchas compañías de las que podrían beneficiarse, eligen no hacerlo. Con la actual expansión de Linux en los mercados de servidor, escritorio y entornos embebidos, es razonable esperar que este número de empresas contribuidoras – y desarrolladores individuales – continúe incrementándose.</font></p> <h2 class="western"> <font color="#000000">Agradecimientos</font></h2> <p> Los autores quieren agradecer a los miles de contribuidores individuales al núcleo; sin ellos, apuntes como éste no interesarían a nadie</p> <h2 class="western"> <font color="#000000">Recursos</font></h2> <p> <font color="#008000"><font color="#000000">También queremos agradecer a Jonathan Corbet su herramienta <em>gitdm</em> que se usó para crear un gran número de estas estadísticas. La información para este artículo fue extraída directamente de las versiones del kernel de Linux encontradas en el sitio web <em>kernel.org</em> y del repositorio <em>git</em> del kernel. Algunos de los <em>logs</em> del repositorio <em>git</em> fueron limpiados a mano debido a los cambios de direcciones de correo a lo largo del tiempo, y correcciones menores en la información de autoría. Se usó una hoja de cálculo para computar las estadísticas. Todos los logs, scripts, y hojas de cálculo se pueden encontrar en </font><a href="http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_history">http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_history</a><font color="#000000">.</font></font></p> <ul> <li> <p> <font color="#000000">Basado en un artículo originalmente publicado en el Simposio Linux 2006</font></p> </li> </ul> Rafa Eska 2010-08-19T08:10:06Z