SafeChildren Banner

Havoc Oracle Solaris Experts

lunes, 28 de junio de 2010

Rendimiento Java NIO en Tomcat 6

Introducción
En el post anterior hablábamos de Cómo Configurar Tomcat 6 para Activar Java NIO, en esta ocasión vamos a ver algunos gráficos sobre el rendimiento Java NIO vs Java IO.

Lo primero que debemos tener en cuenta es que cada aplicación es diferente y por lo tanto, no se puede establecer una regla universal sobre cual de las dos tecnologías en la mejor. Por ello, os recomiendo que utilicéis Pruebas de Rendimiento de Aplicaciones Web con JMeter para poder tomar una decisión sobre Java NIO.

Además, Tomcat 6 está en fase de pruebas y por lo tanto, no está enfocado a producción, sin embargo, GlassFish si que tiene soporte de Java NIO en sus versiones de producción

La Prueba
Para llevar a cabo la prueba de rendimiento he utilizado una aplicación con un servlet que acepta una cadena por parámetros, inserta en la base de datos (PostgreSQL) y devuelve la cadena. Como veis, no es muy complicada, pero para hacer mis análisis era suficiente.

5 Usuarios x 1000 Peticiones usando Default I/O

5 Usuarios x 1000 Peticiones usando NIO


10 Usuarios x 500 Peticiones usando Default I/O


10 Usuarios x 500 Peticiones usando NIO


Resultados Totales
Aquí os dejo un documento con todos los datos del cálculo de rendimiento NIO vs IO para poder analizarlos de una forma más sencilla.



Conclusiones
En nuestro caso, el rendimiento se incrementaba de forma notable cuando teníamos pocos usuarios (dos usuarios)  ya que pasaba de una media de ejecución de 3501s a 939s, sin embargo, cuanto más incrementábamos los usuarios, la diferencia no era tan grande -aunque siempre se obtenía mejor rendimiento con NIO- llegando a 2532s vs 2475s con 10 usuarios y 500 peticiones.

Creo que NIO puede ofrecer mejoras, pero hay que estudiar cada caso con detenimiento.

Referencias

miércoles, 23 de junio de 2010

Activar Java NIO en Tomcat6

Introducción
Una de las características más esperadas que introdujo la versíon 1.4 de Java fue un nuevo sistema de IO adaptado a los sistemas modernos. Esto permitía adaptar el formato de entrada/salida a las nuevas características de las CPUs -principalmente MultiThread- haciendo que las peticiones fuesen "no bloqueantes" y por lo tanto "sean manejadas por threads".  No voy a entrar en mucho detalle sobre cuáles son las diferencias -ya que pienso que es un tema de programación- pero sí que voy a explicar por qué nos aplica en términos de sistemas:
  • No permite escalar más y utilizar mejor los threads de las CPUs. De esta forma, tendremos menos cambios de contexto y por lo tanto mejor rendimeinto
  • Uso de Socket Asíncronos. De esta forma, seremos capaces de soportar más peticiones concurrentes en nuestros servidores de aplicaciones.
  • Podemos usar Resource Control. De esta forma, los límites y uso de recursos están mejor controlados en el sistema.
Sin embargo, no ha sido hasta la versión 6 de Tomcat cuando hemos podido empezar a utilizar esta nueva configuración.


Configuración de Apache Tomcat 6.x
Para activar el funcionamiento NIO en Tomcat 6, siemplemente editaremos el archivo de configuración <CATALINA_HOME/conf/server.xml> y modificaremos el valor de la propiedad:
protocol="HTTP/1.1"
por
protocol="org.apache.coyote.http11.Http11NioProtocol"
Por ejemplo, podemos añadir un nuevo "connector" en el puerto 8585 que use el formano NIO de la siguiente forma:
    <!-- NIO Connector With Compression -->
    <Connector
        maxThreads="256"
        enableLookups="false"
        protocol="org.apache.coyote.http11.Http11NioProtocol"
        keepAliveTimeout="5000"
        maxKeepAliveRequests="1000"
        port="8585"
        connectionTimeout="20000"
        compression="on"
        bufferSize="8192"
        redirectPort="8443"
        URIEncoding="UTF-8"
    />
Conclusiones
Como hemos visto, cambiar al nuevo sistema de IO (NIO) que nos proporciona Java a partir de la versión 1.4.2 es realmente sencillo. En las próximas entregas veremos si -como dicen en Sun- es un sistema revolucionario y proporciona un rendimiento superior en sistemas con mucha carga.

Referencias

miércoles, 16 de junio de 2010

Cambios de Contexto (Context Switch) en Solaris

Introducción
Los cambios de contexto son la acción de almacenar y restaurar los registros de la CPU de un proceso con objeto de poder continuar su ejecución  en otro momento. Básicamente es el mecanismo para poder ejecutar múltiples procesos en una única CPU (multitarea)

Los cambios de contexto pueden ser debidos a eventos de multitarea (realizados por el Sistema Operativo) o por Interrupción Hardware.
  • Los debidos a multitarea se producen cuando dos -o más procesos- están peleando por los recursos del sistema, y o bien se ha quedado a la espera de I/O (waiting) o se ha expirado su tiempo de ejecución máxima. 
  • Los debidos a interrupción por hardware son aquellos que hacen un wake up cuando el hardware necesita que alguien gestione sus datos, por ejemplo una tarjeta de red cada vez que obtiene datos

Para gestionar todo esto tenemos variar opciones: Tipos de Planificadores (TS, FSS, FX, RT, IA) y Procesor Set.

Tipos de Planifcadores "Constantes"
Los tipos de planificadores nos permiten ajustar los parámetros de comportamiento de los procesos en varios aspectos, entre ellos, Tiempos de Ejecución <dentro de la CPU>, Prioridad, etc.

No voy a hacer un comentario muy exhaustivo sobre ellos ya que debo dedicarle un post completo, así que, simplemente deciros que podéis hacer referencia a los post de Cómo cambiar el planificador a un proceso o Cómo cambiar el planificador por defecto de Solaris y esperar a que hablemos de ello en las próximas semanas.

Processor Set
Un pset es un pool de procesadores a los cuales se le asignan unos procesos y éstos no pueden ejecutarse fuera de estos. Dicho de otra forma, supongamos que definimos un pset con las CPUs (1,2,3,4) y otro pset con las CPUs(5,6,7,8) además hacemos que, por ejemplo, Apache Tomcat esté unido al pset1 y que Apache HTTP esté unido al pset2 de esta forma, los <threads> the Tomcat, no "pelearan" por las CPUs con los <threads> de Apache HTTPD obteniendo menos (I)CSW

Coste de Cambio de Contexto
Generalmente supone un coste elevado ya que requiere un tiempo considerable de CPU, por ello, debemos tener en cuenta los valores de CSW -Context SWitch- y ICSW -Involuntary Context SWitch- que nos proporciona el comando </usr/sbin/mpstat>

Conclusión
En esta ocasión hemos visto un poco de teoría sobre el funcionamiento interno y su repercusión el en rendimiento del sistema. Esto, nos ayudará a comprender los siguiente post en los que hablaremos de mejora de aplicaciones J2EE -en cuanto a rendimiento- y continuaremos con la serie de Instalación de Apache Tomcat en Entornos de Producción


Referencias

    jueves, 10 de junio de 2010

    Sincronizar el reloj mediante NTP en OpenSolaris

    Introducción
    La sincronización del reloj mediante NTP en OpenSolaris sigue el mismo procedimiento que Sincronización de Reloj mediante NTP en Solaris, por ello, simplemente vamos a hacer un repaso rápido de cómo hacerlo.

    Vamos a utilizar el pool ntp de Europa para configurar nuestros servidores, sin embargo, podemos utilizar cualquier servidor NTP público/privado que queramos.
    itily@matxinsalto:~$ pfexec vi /etc/inet/ntp.conf
       server 0.europe.pool.ntp.org
       server 1.europe.pool.ntp.org
       server 2.europe.pool.ntp.org
       server 3.europe.pool.ntp.org
    :wq
    itily@matxinsalto:~$ pfexec svcadm enable ntp
    itily@matxinsalto:~$ pfexec svcs ntp
    STATE          STIME    FMRI
    online         18:49:41 svc:/network/ntp:default
    itily@matxinsalto:~$ dmesg | tail -2
    May 24 18:49:41 matxinsalto ntpd[926]: [ID 702911 daemon.notice] ntpd 4.2.5p172@1.1845-o Tue Feb 16 02:30:48 PST 2010 (1)
    May 24 18:49:41 matxinsalto ntpd[928]: [ID 702911 daemon.notice] proto: precision = 0.398 usec

    martes, 8 de junio de 2010

    Herramientas de Test de Solaris - AMT Common Criteria Security

    Introducción
    En Solaris disponemos de diferentes herramientas que nos proporciona información sobre el estado del hardware. Hoy vamos a hablar de AMT <Abstract Machine Test>

    # amt

    AMT Test Program -- 64 bit application
    ================


    Test 1- stack Side Boundary Test
    TEST 1 PASSED


    Test 2- Data Side Boundary Test.
    PASS: Successful read/write in data area.
    TEST 2 PASSED


    Test 3- Text Area Not Writeable
    Verify that a write to the text space does not cause a write to the executable
    file from which it came, or to another process which shares that text.
    PASS: Caught the segmentation fault, meaning we can't write to text area.
    TEST 3 PASSED


    Test 4- Memory Not Shared After Write
    Verify that anonymous memory initially shared by two processes (e.g. after a
    fork) is not shared after either process writes to it.
    TEST 4 PASSED


    Test 5- Memory Allocation is Not Shared
    Verify that newly allocated memory in one of two processes created by forking
    does not result in newly allocated memory in the other.
    Parent address of hole before child change: 0010D130
    Child end of hole before change:  0010D130
    Child end of hole after change: 0010F130
    Parent address of hole after child change: 0010D130
    PASS: Hole is same size in parent.
    TEST 5 PASSED

    TESTS SUCCEEDED

    Referencias

    viernes, 4 de junio de 2010

    Instalar ISC DHCP en Solaris 10

    Introducción
    En esta ocasión vamos a ver Cómo Instalar un Servidor DHCP Paso a Paso en Solaris 10. Tener en cuenta que Solaris cuenta con un servidor DHCP, sin embargo, vamos a utilizar el que nos proporciona ISC ya que es muy ligero y sencillo de configurar, además, es el servidor DHCP "de facto" en FreeBSD.

    Compilación de ISC DHCP
    Lo primero que debemos hacer es decargarnos el código fuente desde la web de ISC, en nuestro caso vamos a utilizar la versión 4.1.1-P1 que no tiene dependencias con BIND. Lo configuraremos con las opciones <paranoia> y con un <prefix> personalizado para que se instale en el directorio </opt/dhcpd>
    $ wget http://ftp.isc.org/isc/dhcp/dhcp-4.1.1-P1.tar.gz
    $ gtar zxpf dhcp-4.1.1-P1.tar.gz
    $ cd dhcp-4.1.1-P1
    $ ./configure --prefix=/opt/dhcpd --enable-paranoia
    $ make
    # make install
    Instalación
    Vamos a crear un usuario llamado <dhcp>, grupo <dhcpd> y project para el grupo <group.dhcpd>
    # groupadd dhcpd
    # useradd -g dhcpd -s /bin/false -d /dev/null -g dhcpd dhcpd
    # projadd -c 'DHCP Project' group.dhcpd
    Creación de la base de datos de concesiones y PID
    Debemos crear el archivo que contendrá las concesiones creadas, ya que ISC DHCP no lo creará, en nuestro caso vamos a utilizar el directorio </var/dhcpd> para almacenar el pid y la base de datos. Estos parámetros son configurables como veremos más adelante
    # mkdir /var/dhcpd
    # chown dhcpd:dhcpd /var/dhcpd
    # chomod 700 /var/dhcpd
    # touch /var/dhcpd/dhcpd.leases
    Configuración del Servidor ISC DHCP
    El archivo de configuración se encuentra en <$DHCP_HOME/etc/dhcpd.conf> y su estructura es muy sencilla. Todas las líneas de configuración deben acabar con <;>, sino el servidor no se iniciará y nos indicará que hay un error en el archivo de configuración.
    Dentro de él tendremos la sección "global" -que será todo el archivo- y diferentes "subsecciones" identificadas como:
    _nombre_ {
     option ...  ;
     option ...  ;
    }
    Tenemos el archivo de configuración con varios ejemplos que podemos utilizar para comenzar con nuestro propio diseño, por ello, vamos a realizar una copia -por si acaso- y siempre podremos verificar la sintaxis del archivo de configuración
    # cat dhcpd.conf > dhcp.conf.ORIGINAL
    Simplemente modificaremos los siguientes parámetros del archivo
    option domain-name "test.com";
    option domain-name-servers ns1.test.com, ns2.test.com;
    authoritative;
    log-facility local5;
    A continuación declararemos el rango DHCP que queremos ofrecer, para ello, debemos crear una subsección por cada uno de los rangos, en nuestro ejemplo, para el rango 192.168.25.0
    subnet 192.168.25.0 netmask 255.255.255.0 {
      range 192.168.25.5 192.168.25.200;
      option domain-name-servers ns1.internal.test.com;
      option domain-name "internal.test.com";
      option routers 192.168.25.254;
      option broadcast-address 192.168.25.255;
      default-lease-time 600;
      max-lease-time 7200;
    }
    Si queremos añadir soporte para que nuestro DHCP exporte el archivo de configuración del proxy, deberemos incluir en la sección global -después de <authoritative>- las siguientes entradas
    # PAC Support
    option local-pac-server code 252 = text;
    option local-pac-server "http://URL_del_proxy/proxy.pac";
    Configuración SysLog
    Hemos definido como parámetro <log-facility local5> para ello, vamos a declararlo en nuestro syslog
    # vi /etc/syslog.conf
      # DHCP Log
      local5.debug                                    /var/log/dhcpd.log
     :wq
    # touch /var/log/dhcpd.log
    # chmod 600 /var/log/dhcpd.log
    # chown root:sys /var/log/dhcpd.log
    # svcadm restart system-log
    Configurar el servicio mediante Solaris SMF
    He creado los archivo de <manifest y method> para estos servicios o podéis crear los vuestos  si queréis, podéis descargar Manifest para ISC DHCP Solaris 10 SMF y el Method ISC DHCP Solaris 10 SMF
    # cd /lib/svc/method
    # /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/isc-dhcp-solaris/svc/isc-dhcp_4
    # chown root:sys isc-dhcp_4
    # chmod 555 isc-dhcp_4
    # /var/svc/manifest/network
    # /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/isc-dhcp-solaris/svc/isc-dhcp_4.xml
    # chown root:sys  isc-dhcp_4.xm
    # chmod 444 isc-dhcp_4.xml
    # svccfg
    svc:> validate isc-dhcp_4.xml
    svc:> import isc-dhcp_4.xml
    svc:> quit
    # svcs isc-dhcp_4
    STATE          STIME    FMRI
    disabled       12:38:48 svc:/network/isc-dhcp_4:default_32bits
    # svcadm enable isc-dhcp_4
    # svcs isc-dhcp_4
    STATE          STIME    FMRI
    online         12:40:08 svc:/network/isc-dhcp_4:default_32bits
    Conclusión
    El servidor DHCP de ISC nos permite una puesta en marcha muy rápida, y es muy sencillo de administrar. Además al incluirlo dentro del framework de SMF podemos gestionarlo de forma sencilla igual que otro servicio más.

    Referencias