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
Blog donde comento mis historias con el sistema operativo Sun Solaris durante todos estos años de lucha y placer.
lunes, 28 de junio de 2010
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:
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:
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
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.
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 -->Conclusiones
<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"
/>
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.
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
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
- Cambios de Contexto (Wikipedia)
- Cómo asociar un proceso a un procesador en concreto
- Cómo cambiar el planificador de un proceso
- Cómo cambiar el planificador por defecto de Solaris
- Comandos Básicos y No tan Básicos de Solaris
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.
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>
Referencias
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>
Vamos a crear un usuario llamado <dhcp>, grupo <dhcpd> y project para el grupo <group.dhcpd>
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
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:
Hemos definido como parámetro <log-facility local5> para ello, vamos a declararlo en nuestro syslog
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
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
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.gzInstalación
$ gtar zxpf dhcp-4.1.1-P1.tar.gz
$ cd dhcp-4.1.1-P1
$ ./configure --prefix=/opt/dhcpd --enable-paranoia
$ make
# make install
Vamos a crear un usuario llamado <dhcp>, grupo <dhcpd> y project para el grupo <group.dhcpd>
# groupadd dhcpdCreación de la base de datos de concesiones y PID
# useradd -g dhcpd -s /bin/false -d /dev/null -g dhcpd dhcpd
# projadd -c 'DHCP Project' group.dhcpd
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/dhcpdConfiguración del Servidor ISC DHCP
# chown dhcpd:dhcpd /var/dhcpd
# chomod 700 /var/dhcpd
# touch /var/dhcpd/dhcpd.leases
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_ {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
option ... ;
option ... ;
}
# cat dhcpd.conf > dhcp.conf.ORIGINALSimplemente modificaremos los siguientes parámetros del archivo
option domain-name "test.com";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
option domain-name-servers ns1.test.com, ns2.test.com;
authoritative;
log-facility local5;
subnet 192.168.25.0 netmask 255.255.255.0 {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
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;
}
# PAC SupportConfiguración SysLog
option local-pac-server code 252 = text;
option local-pac-server "http://URL_del_proxy/proxy.pac";
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.logConfigurar el servicio mediante Solaris SMF
# chmod 600 /var/log/dhcpd.log
# chown root:sys /var/log/dhcpd.log
# svcadm restart system-log
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/methodConclusión
# /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
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
Suscribirse a:
Entradas (Atom)