JAVA SERVER PERFORMANCE - Lo que un arquitecto de software sí puede hacer

"HotRockit". La convergencia entre las JVMs Hotspot (Sun) y JRockit (Oracle-Bea)

2011-11-30T17:45:00.002+01:00

Por fin se empiezan a ver los resultados de la cacareada convergencia entre las máquinas virtuales Hotspot y JRockit...

Aunque de momento sólo tengamos poco más que el audio y las slides de la JavaOne 2011sobre las "líneas generales" de la convergencia:
What to Expect from HotRockit, by Marcus Hirt

¿Se acabó el espacio permanene "permgen"? ¿en serio? (sólo por este dolor de cabeza de Hotspot merece la pena la fusión :-)
¿"Flight Recorder" para viajar atrás en el tiempo y ver qué causó una incidencia?
...

JRockit es ahora gratuíto

2011-05-31T12:56:00.003+02:00

Pues eso. Más información, letra pequeña y q&a en el blog de Henrik Stahl:

JRockit is Now Free (and Other Java License Updates)

:-)

Mucho cuidado con @Singleton

2011-05-30T14:07:00.005+02:00

Me permito referenciar, como nota mental, el siguiente post de Adam Bien:

@SINGLETON - THE PERFECT CACHE FACADE

Donde avisa de:
@Singleton in the default configuration is the perfect bottleneck (...) The annotation @ConcurrencyManagement(BEAN) deactivates this limitation (...)

Para más información, ver el resto del post referenciado y el see also que marca.

Actualización del post "Tuning de NetBeans 7.x y 6.x"

2011-04-27T13:47:00.002+02:00

Actualizado el post Tuning de NetBeans 7.x y 6.x, al que incluso le he cambiado el nombre.

Lo más importante (y lo dejo aquí para mi propio recuerdo):

Mi fichero netbeans.conf contiene las siguientes opciones de lanzamiento:

###[serverperformance.blogspot.com] netbeans_default_options="-J-Dcom.sun.aas.installRoot=\"C:\Java\glassfish-v2ur2\" -J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=500m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J-Djava.index.useMemCache=true -J-Xverify:none -J-XX:+UseBiasedLocking -J-XX:+AggressiveOpts -J-Djava.net.preferIPv4Stack=true -J-Dsun.java2d.d3d=true -J-Dsun.java2d.noddraw=false -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true "

Tiered compilation en Hotspot 20 (Java 6u25)

2011-04-24T23:13:00.006+02:00

Mientras seguimos esperando el cierre de versión de Java 7 (las listas de correo andan ardiendo estas últimas semanas, pero aún tardará), hace unos días salió Java 6 Update 25, donde por fin se incluye Hotspot 20. Aparte de que está también recién horneado Netbeans 7.0 (yo llevaba tiempo trabajando con las release candidates)...

A diferencia de los últimos updates, este sí promete mejoras de rendimiento, aunque la mala noticia es que el G1 (Garbage First) continúa en modo experimental... pero la buena noticia es que parece que la tiered compilation por fin parece que funciona, ¿habrá llegado el esperado maná, lo mejor de los dos mundos (-client y -server) en uno

Pego algunos extractos de las releases notes:

(...)
Java Hotspot VM 20
(...) contains improvements to performance, reliability and diagnostic information.

A new feature in this version of HotSpot is "tiered" compilation in the Server VM that enables it to start quickly as does the Client VM, while achieving superior peak performance. This feature is enabled by specifying -server and -XX:+TieredCompilation command options.

The Garbage First (G1) garbage collector continues to advance with Java SE 6u25, although it remains an experimental option.

HotSpot diagnostic information has been expanded in several ways (...)

Performance Improvement to BigDecimal
Improvements have been made to class BigDecimal enhancing its performance by thirty percent. BigDecimal is enabled by specifying -XX:+AggressiveOpts command option.

Performance Improvement to java.util.logging.LogRecord
The performance of the class java.util.logging.LogRecord has been enhanced. This enhancement improves the efficiency of including source class and method names in java.util.logging log records.
(...)

Y más información sobre "tiered compilation", por el ínclito Remí Forax, en http://weblogs.java.net/blog/forax/archive/2010/09/05/tiered-compilation, de donde me permito extraer:

"Tiered compilation in hotspot is an old dream. Hotspot has two JITs named c1 aka client JIT and c2 aka server JIT. The client JIT starts fast but provides less optimizations so it is used for GUI application. The server JIT starts more slowly but provide very good optimizations.
The idea of tiered compilation is to get the best of both compilers, first JITs the code with c1 and then if the code is really hot to recompile it with c2."

Obviamente en ejecuciones a largo plazo el "tiered compilation" no supone mejora general, pero sí durante los primeros minutos. He probado (como mera prueba) el arranque de Netbeans con -server -XX:+TieredCompilation y el rendimiento se aproxima a -client (al menos es infinitamente mejor que con -server), aunque a cada cosa lo suyo, para aplicaciones gráficas y applets, seguirá siendo mejor el compilador cliente (por ahora, quizás algún día deje de existir la doble opción)

Recopilando algunas de las últimas recomendaciones para aplicaciones servidor en arquitecturas de 64 bits que soporten NUMA, recomiendo probar estas opciones de arranque (con Java 6 u25 / Hotspot 20):

-server -XX:+TieredCompilation -XX:+UseCompressedOops -XX:+UseNUMA -XX:+UseParallelOldGC -Xverify:none -XX:+UseBiasedLocking -XX:+AggressiveOpts -Djava.net.preferIPv4Stack=true

(aparte de los valores adecuados a cada caso para -Xms -Xmx -Xss -XX:PermSize -XX:MaxPermSize)

-XX:+UseNUMA

2011-02-08T22:17:00.006+01:00

Creo que desde Hotspot 17, al menos, está disponible esta opción (ahora vamos por Hotspot 19 con el JDK 1.6.0_23). Para mejorar el rendimiento de la recolección de basura en arquitecturas multicore, lo que según Sun-Oracle supone en total hasta una mejora de entre un 30 y un 40% en SPEC JBB 2005.

¿Pero qué es NUMA? Pues ala, a verlo en la wikipedia: http://es.wikipedia.org/wiki/NUMA.

En http://download.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#numa puede verse un resumen de la utilidad de esta opción en combinación con -XX:+UseParallelGC (o -XX:+UseParallelOldGC):

NUMA Collector Enhancements
The Parallel Scavenger garbage collector has been extended to take advantage of the machines with NUMA (Non Uniform Memory Access) architecture. Most modern computers are based on NUMA architecture, in which it takes a different amount of time to access different parts of memory. Typically, every processor in the system has a local memory that provides low access latency and high bandwidth, and remote memory that is considerably slower to access.

In the Java HotSpot Virtual Machine, the NUMA-aware allocator has been implemented to take advantage of such systems and provide automatic memory placement optimizations for Java applications. The allocator controls the eden space of the young generation of the heap, where most of the new objects are created. The allocator divides the space into regions each of which is placed in the memory of a specific node. The allocator relies on a hypothesis that a thread that allocates the object will be the most likely to use the object. To ensure the fastest access to the new object, the allocator places it in the region local to the allocating thread. The regions can be dynamically resized to reflect the allocation rate of the application threads running on different nodes. That makes it possible to increase performance even of single-threaded applications. In addition, "from" and "to" survivor spaces of the young generation, the old generation, and the permanent generation have page interleaving turned on for them. This ensures that all threads have equal access latencies to these spaces on average.

The NUMA-aware allocator is available on the Solaris™ operating system starting in Solaris 9 12/02 and on the Linux operating system starting in Linux kernel 2.6.19 and glibc 2.6.1.

The NUMA-aware allocator can be turned on with the -XX:+UseNUMA flag in conjunction with the selection of the Parallel Scavenger garbage collector. The Parallel Scavenger garbage collector is the default for a server-class machine. The Parallel Scavenger garbage collector can also be turned on explicitly by specifying the -XX:+UseParallelGC option.

NUMA Performance Metrics
When evaluated against the SPEC JBB 2005 benchmark on an 8-chip Opteron machine, NUMA-aware systems showed the following performance increases:
32 bit – About 30 percent increase in performance with NUMA-aware allocator
64 bit – About 40 percent increase in performance with NUMA-aware allocator

¡¡¡Lástima que con el kernel 2.6.18 (que es el de mis sistemas de producción) no se soporta!!!

Sin haber hecho pruebas, estoy convencido en que en aplicaciones servidor (que efectivamente cumplen el patrón típico de toneladas de objetos creados y consumidos únicamente por el mismo thread) la ganancia será palpable en casi todos los escenarios, o cuando menos inocuo. Probablemente en algunas situaciones, sin embargo, sea peor el remedio que la enfermedad...

Azul Zing

2010-08-27T16:21:00.008+02:00

Me hago eco del último newsletter en http://www.javaperformancetuning.com/, que la verdad parecía que esto iba a perder interés y ha entrado un nuevo jugador en el match de las JVM sobre arquitecturas x64... Azul Systems, que da el salto por fin y ha portado su Zing VM (anteriormente sólo disponible para su arquitectura sobre procesadores Azul Vega).

http://www.javaperformancetuning.com/news/news117.shtml

"Until now, if you wanted to eliminate all but the tiniest GC pauses (e.g. everything over 1 millisecond), you had to either program in a very non-object oriented way (almost eliminating object creation and destruction); or program in a specialized way to the Java Realtime System, or sometimes you would be lucky and the Oracle) JRockit Real Time or IBM WebSphere Real-time would work well on your app and keep the GC pauses right down there.

But now Azul are providing a mainstream option that specifically targets keeping GC pauses tiny for the majority of Java applications, giving us all a new option with their new Zing product and the Managed Runtime Initiative. This is great news since with Oracle owning both JRockit and HotSpot, competitive
pressures on JVM evolution were hugely reduced. And what competition Azul are providing: with GC pauses typically under 1 millisecond even for 100GBs heaps, and even the occasional longer GC pause still only into the 10-20 millisecond range! (Gil Tene, Azul's CTO, says as far as they can tell these longer GC pauses are caused by the OS context switching during a GC pause, and not because the GC pause actually takes any longer).
(...)
Previously, Azul was a very niche competitor - you had to buy their hardware if you wanted their low pause Java runtime, and typically that was only going to fly if you needed very large scaled JVMs. For the smaller low latency application that desperately wanted low pause GCs, Azul didn't even feature on the evaluation list. But now Azul has ported their runtime to run on Intel and AMD processors, suddenly this is an option for many more applications. And Azul haven't stopped there, they've also created the Managed Runtime Initiative (MRI) to provide a free JVM option with those incredibly low GC pauses. To enable this, they've contributed kernel changes to linux and implemented a Java Runtime based on openjdk - it's all available from the MRI site; and although currently it's only an alpha release, Azul are intending to stabilize the combination to a fully supported release.

This is not only serious new competition for Oracle's JVM, but realistically targets two of the four top JVM performance challenges (GC pause times and very large heaps; the other two are higher visibility into production runtimes; and transparently utilising multiple cores). Java long ago reached production maturity capable of handling almost anything thrown at it but, every time I think Java might be slowing down, yet another brilliant change happens in the Java space to make it yet better again. Amazing that after 15 years on the leading edge, it just carries on staying right there."

Recomiendo leer la newsletter íntegra Y SUSCRIBIRSE A LA MISMA, yo llevo ya unos añicos... :-)

http://www.javaperformancetuning.com/news/news117.shtml

Escalabilidad en cuanto a capacidad de poner en producción nuevas funcionalidades

2009-04-24T18:27:00.001+02:00

Me ha resultado muy interesante este artículo del blog de uno de los fundadores de FriendFeed (y que anteriormente fue un mando intermedio en Google): http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Con una base de datos con decenas o cientos de millones de entradas, se encontraron un problema de escalabilidad entre otras cosas en la adición de nuevas funcionalidades, en concreto en el tiempo que cuesta añadir o quitar columnas a tablas, o añadir índices o eliminarlos. Estamos hablando de una o varias horas de "no disponibilidad de la BD" en un sistema supuestamente 24x7 :-)

Así que la solución (no sólo para ese problema, sino también por estabilidad en los tiempos de respuesta, cosa que no termino de enteder por cierto) fue la que se describe en la mencionada entrada. Resumidamente, usar MySQL como motor de almacenamiento pero pasar como de la mierda de un modelo relacional...

Enriquecedora lectura, aunque no me aplique... (que yo sepa ;-)

Java 6u13

2009-04-15T15:22:00.001+02:00

Desde hace 3 semanas, está disponible el update 13 de Java 6. Descargas aquí: http://java.sun.com/javase/6/

Recordemos que a partir del update 10, la política de versiones de Java SE es:

Las versiones pares incluyen mejoras y/o nuevas funcionalidades (además de parches de seguridad si aplican).
Mientras que las versiones impares están reservadas para contener exclusivamente (salvo excepciones).

En este caso, como puede verse en http://java.sun.com/javase/6/webnotes/6u13.html, se han corregido 7 vulnerabilidades y se ha aprovechado para corregir otros 7 bugs no relacionados directamente con la seguridad pero que se han considerado prioritarios.

Seguimos esperando ansiosos la inminente liberación del update 14 (Java 6u16), que supondrá un hito importante en cuanto a rendimiento (es decir incluirá todo lo experimentado en las performance releases del año pasado y más cosas :-)

Y... La 6u14 ya va por la build b04, lo que significa que estamos muy cerquita aunque este update yo creo que necesitará algunos más de lo habitual, seguramente será a mediados o finales en mayo cuando se libere, como llevamos tiempo precidiendo desde este blog. Más información y descargas de los snapshots: http://download.java.net/jdk6/6u14/

Incremento de un 100% de rendimiento de java.util.Logger (o los detalles sí importan)

2009-04-08T22:52:00.000+02:00

Delicioso post de Jeremy Manson, que lleva tiempo teniéndnos "abandonaditos"...:

http://jeremymanson.blogspot.com/2009/04/faster-logging-with-faster-logger.html

A raíz de la necesidad de un cliente, que quería nada menos que un throughput de 2 MB por segundo en la escritura de logs (!), se han hemos una serie de optimizaciones en Logger.log para alcanzarlo, y se ha alcanzado...

Los cambios ya están disponibles en el último build de OpenJDK, y más detalles en http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6797480.

El código de Jeremy es precioso en si mismo (lo siento, seguramente un no-programador no puede entender el adjetivo precioso aplicado a esto). Toda una clase de sincronización y volatilidad. Y es el mejor ejemplo de que el mejor "Escape analysis" sigue haciéndolo el ingeniero...

Pero, y por mucho que él le quite culpas al desarrollador original de esa clase (incorporada en JDK 1.4)... joder ¿eso siempre ha estado ahí? ¿los procesos de entrega de Sun Microsystems no incluyen búsqueda de puntos calientes o locks adquiridos en cada thread?

Lo cierto es que me ha dejado un sabor de boca muy muy agridulce...

Deja de hibernar y despierta de una vez!

2009-04-02T05:58:00.000+02:00

Me hago eco de este artículo: "Good Advice on Keeping Your Database Simple and Fast".

Independientemente de si nos parece bien, mal o regular todo lo demás, de si creemos en SimpleDB y S3 o no... e independientemente de si todo este rollo del Cloud mola pero no te aplica porque tus problemas son otros, tú trabajas en un sistema de información interno...

...El primer párrafo del artículo es para enmarcarlo, y traduzco literalmente:

Mantener una base de datos simple y rápida es muchas veces complicado si se usan frameworks de alto nivel como (...) o tecnologías de persistencia de objetos en Java como HIBERNATE. Hay una gran cantidad de "magia" que ocurre fuera de tu vista sobre la que no tienes ningún control. Si tienes que escalar tu aplicación, generalmente son estas tecnologías para acceder a bases de datos relacionales las que se convierten en el cuello de botella tanto de rendimiento como de escalabilidad. (...)

¡Algo sensato! ¡Por fin! Por favor que vuelvan los tiempos del JDBC crudo (dentro o fuera de un EJB). Y no necesariamente implica perder el tiempo en codificar como un mulo.

Ya en el año 2001 en mi anterior empresa ideé y lideré un sistema que llamamos "BeanBuilder" para generar todo tipo de código a partir del esquema de base de datos. Y no sólo me refiero a los EJB con altas/bajas/modificaciones/consultas/filtros/paginación, sino incluso llegamos a generar operativas completas con sus JSP de listado y de formularios de alta en base a plantillas. Para que sirvan como base para modificarlos, ampliarlos, etc. Pero siempre con control sobre el código generado porque generábamos código Java.

Y allá por 2004 el sistema era realmente complejo, admitíamos tomar como punto de partida joins entre varias tablas y generar lo apropiado... Teníamos un formulario en el que elegías el tipo de framework que debía utilizar el código generado (¿EJB o framework propio con POJO? ¿JSP o XSLT? ¿Struts o nuestro framework propio?). Vamos, una herramienta para cualquier proyecto que abordáramos...

Es decir si el objetivo es ahorrar esas horas de desarrollo "que no aportan valor" pero mantener el control sobre lo que potencialmente te va a dar problemas.

No preguntéis el motivo, pero quedó en vía muerta. Si volviera a quella época hubiera lanzado un proyecto Open Source en toda regla...

¡Es hora de despertar de la "hibernación" en que estos arquitectos de salón nos han metido!

Un medio, no un fin

2009-03-25T01:15:00.002+01:00

Sin que sirva de precedente tiene poco que ver con el tema de este blog (o mucho si se piensa bien).

Me ha llamado la atención el primer párrafo de un artículo sobre ENS (es de 2003, no digo que el estudio en si mismo sea interesante):

"Ejecutivos y gerentes se esfuerzan por satisfacer las necesidades de los clientes y de los accionistas de manera simultánea"
(http://files.epsscentral.info/gery/pdfarticles/Enterprise%20Nervous%20System.pdf)

Ahí está la madre del cordero. El arte de gestionarlo. Como me dijo un sabio (Zape) una vez: no te olvides de quién te paga el sueldo. O lo que es lo mismo, no olvidemos que las cosas las hacemos por un objetivo.

Aunque para obtener ese objetivo como precio a pagar haya que satisfacer al cliente. Esta frase es de otro sabio, Zipi ;-)

La tecnología al servicio del negocio. No al revés. Pero qué fácil es olvidarlo cuando no estás en primera línea...

¡Qué gran pareja estos Zipi y Zape! Lástima que siguieran sus carreras musicales por separado...

Y aplicado a la temática de este blog: el rendimiento y escalabilidad es un medio, no un fin.

:-/

SaaS, IaaS y PaaS: Las tres clases de Cloud Computing

2009-03-20T02:17:00.002+01:00

Lo único que está claro es que Cloud Computing es un palabro guay para poner en las PPT. Es como lo de la Web 2.0 o SOA, que nadie sabe lo que es pero todo el mundo habla de ella. Y en una reunión nadie pregunta qué es por miedo al ridículo.

Esta es la única catalogación clara que hay por ahí en castellano, en Nubeblog:

http://www.nubeblog.com/2008/10/15/saas-iaas-y-paas-las-tres-clases-de-cloud-computing/
Claro y conciso. De verdad.

Yo tengo mi propia opinión y creo que hay modelos mixtos y valores añadidos muy diferenciados de un SaaS a otro, como para meterlos en el mismo saco. Pero para gustos los colores: del mismo modo que hay quien asegura que AJAX/RIA no es Web 2.0, hay quien asegura que SaaS no es Cloud, cuando para mi en realidad es el nivel más completo de CC: te doy un software y te lo evoluciono, en una infraestructura remota de la yo gestiono su crecimiento, gestión del centro de respaldo, procedimientos de paso a contingencia, help desk 24x7, y todos los servicios asociados... eso sí que es una nube :-)

Otra cosa es que un SaaS pueda apoyarse (o no) en un IaaS y/o en un PaaS. Pero al cliente final se la debería traer floja...

Compressed pointers. Compressed oops.

2009-03-13T12:35:00.000+01:00

Una de mis optimizaciones favoritas que aparecerán en la update 14 de Java 6 (actualmente en build 1, como os indiqué en un artículo anterior), y que ya estaba disponible en las "performance releases" es la compresión de punteros en la máquina virtual de 64 bits.

En Sun le llaman "compressed oops".

El concepto es sencillo, y en realidad desde hace muuuuuucho lo tiene implementado JRockit, si los objetos mapeados es inferior de 4.000 millones de objetos (unos 32 gigas de RAM), se activa esta optimización, que reduciéndolo mucho puede explicarse de la siguiente manera: no es necesario que los punteros sean de 64 bits, pueden ser de de 32 bits, y hacer la resta con el punto de inicio de la memoria del S.O. utilizada. Esto es una reducción, en realidad es más complejo claro... Según el enlace que pongo abajo, literalmente: "Compressed oops represent managed pointers (in many but not all places in the JVM) as 32-bit values which must be scaled by a factor of 8 and added to a 64-bit base address to find the object they refer to. This allows applications to address up to four billion objects (not bytes), or a heap size of up to about 32Gb. At the same time, data structure compactness is competitive with ILP32 mode."

Esto puede consiguir una mejora general del rendimiento de aproximadamente un 3%: Por un lado se consigue que todas las estructuras internas ocupen menos memoria (los punteros ocupan la mitad, y en algunos informes se habla de un consumo de hasta 1,5 veces mayor porque aquí hay mucho puntero aunque lo primero que nos dicen cuando aprendemos Java es que aquí no hay ni un solo puntero) y por otro lado se incrementa la capacidad de las cachés del servidor y of course por los buses puede trasitar el doble de información (en lo que a punteros se refiere) en el mismo tiempo.

Obivamente el mapeo siempre hay que hacerlo y supone una penalización, pero la ganancia por el otro lado lo compensa con creces. Es decir, la máquina virtual de 64 bits será "casi" tan competitiva como la de 32 bits, no llegará a ser lo mismo pero la diferencia será inapreciable...

Aunque algunos piensan que esta optimización sólo funciona si el heap máximo es inferior o igual a 4 GBytes (por aquello de los 32 bits), no es cierto. Como digo arriba son 2^32 objetos referenciados por los punteros. Claro, si cada punterio apuntara a una estructura de 1 byte, esto sería 2 gigas, pero según las medias estadísticas de tamaño de objetos en heap, en la práctica supone aproximadamente 32 gigas efectivos teniendo en cuenta que esta optimización sólo afecta al código compilado no al interpretado, y en función del caso de uso esto es mucho mayor... vamos que la optimización afecta al 99% de los sistemas del mundo mundial.

¿Te suena la frase de que las máquinas virtuales de 64 bits son más lentas o que consumen más memoria? Bien, pues ya no será una afirmación válida...

Más información sobre compresión de punteros, el primer enlace es el clarificador:

Los finalizers no son tus amigos (parte II)

2009-03-06T13:34:00.008+01:00

Juro por la gloria de que James Gosling que ha sido casualidad... Al hilo de lo que comentábamos el lunes... [Viene del artículo anterior: Los finalizers no son tus amigos]

Estoy suscrito a algunas listas de correo del desarrollo de JDK 7 y precisamente ayer jueves se recibía una notificación de un nuevo changeset que optimiza la gestión de PKCS#11 en el proveedor criptográfico del JDK, gracias a eliminar el método finalize() y cambiar su implementación por una weak reference. ¿Os suena???

El webrev completo puede verse en: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da9d0283a496

La descripción es:

Issue: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes with PCKS11 provider.
Summary: Removed finalize() and add more error handling to native code.

Author: valerie
Reviewed-by: vinnie

Los finalizers no son tus amigos

2009-03-02T21:41:00.002+01:00

Gracias al artículo de este mes de javaspecialists.eu (http://www.javaspecialists.eu/archive/Issue170.html), he redescubierto que hay que evitar la implementación del método finalize() siempre que sea posible.

¿Por qué? Porque se añaden handlers a todas y cada una de las intancias de una clase que tenga ese método implementado. ¿Y qué? pues por un lado se añade más footprint de memoria a cada objeto, pero lo más importante: porque un objeto con finalizador es más costoso de alojar, y más costoso de eliminar: la VM añade un hook al objeto que causa que la instancia "sobreviva" a muchos de los pasos de la recolección de basura en lugar de ser retirado rápidamente, por lo que se promociona de forma prematura (y posiblemente innecesaria) dicha instancia a la zona de "old generation". Y esto a su vez hace que el old generation GC tenga más trabajo y se haga más lento y consuma más CPU. Según se apunta por ahí, esta situación puede mejorarse tuneando los ratios de tamaños, pero aún así el coste es importante.

Pero... -te estarás diciendo- si yo necesito un finalizador para cerrar un stream!!! (o cualquier otro recurso). Bueno, puede que sí, puede que no. Revísalo ¿seguro? ¿o lo haces por comodidad? ¿o porque no te fías de que la VM haga lo que tiene que hacer? ¿o porque quieres ayudar al GC (y la cagas, como siempre)? :-)

Si sigues estando seguro de que lo necesitas, dos comentarios:

Ok, pues no pasa nada. No he dicho que no uses finalizadores, sólo que los uses cuando sea absolutamente necesario. Ten en cuenta que este tip es de un nivel muy "fino". Si ese objeto no afecta al rendimiento global por no ser uno de los más utilizados ni entrar en hotspots, pues no te preocupes, recuerda la regla del 90-10.
Si necesitas tunear un caso concreto, y no has visto la forma de simpliciarlo reordenando otras partes del código, siempre puede reemplazarse un método finalize por un establecimiento de una referencia débil (weak) al objeto, y llamando explícitamente aun método equivalente que libera recursos cuando dicha referencia se establece a null.

Nota: esto es así siempre que el finalizador sea "no trivial" (entendiendo por trivial = vacío en tiempo de ejecución) es decir que si dejamos el método en nuestra clase pero su cuerpo está vacío, o si el optimizador del Hotspot mediante inlining lo vacía ("if (false) {...}"), lo dicho anteriormente no se considera: sólo se añaden hooks a objetos con finalizadores no triviales.

Más información:

Ahora repite conmigo:
Los finalizers no son mis amigos.... Finalizer malo, finalizer malo...

[Continúa en el siguiente post: Los finalizers no son tus amigos (parte II)]

Java 6u12 (production) y Java6u14 (early access)

2009-02-24T15:01:00.008+01:00

Pues como anuncié en el post Schedule de siguientes updates de Java 6. Versiones de Hotspot y compatibilidad entre ellas, Sun se está ciñendo al calendario que me pasó mi contacto del equipo de Hotspot:

Ya está disponible Java 6 update 12 para descarga general y soporte para su uso en producción (http://java.sun.com/javase/downloads/index.jsp):

Las mejoras de rendimiento parecen únicamente ceñidas (una vez más!) al entorno cliente y gráfico.
No contiene corrección de ninguna vulnerabilidad de seguridad
La lista de bugs corregidos es importante, aunque los relativos a hotspot y a las bibliotecas core es muy reducida.
Soporte a Windows 2008 Server
[pero no incorpora Hotspot 12 sino que se mantiene Hotspot 11, supongo que han dejado en vía muerta las versiones 12 y 13]

Asimismo, lo que confirma a mi juicio la fecha estimada de mayo, podemos ya descargar Java 6 update 14 "Early Access" desde https://jdk6.dev.java.net/6uNea.html y http://download.java.net/jdk6/6u14/.

Esta versión incorpora la esperada V14 de Hotspot (que ya traía la fracasada versión 6u6p)
Y el anunciadísimo colector de basura Garbage-First (G1), que será el futuro recolector por defecto en entornos servidor aunque en este early access no está habilitado por defecto (ver instrucciones para hacerlo).
Todavía es el build 01, así que viendo la media de builds por versión, aún quedan tres :-)

Lo dicho, yo me espero a verano y migraré directamente de la u11 a la u14... lo cual no quita para que este comienzo de año sea emocionante desde el punto de vista de mejoras de rendimiento en Java, las cuales afortumadamente están aplicando a Java 6 y no sólo a la versión-que-algún-día-dejará-de-ser-beta Java 7.

P.D: Los últimos builds del JDK 1.7 ya incorporan el Hotspot 15...

:-)

Good bye Mr. Monson-Haefel

2009-02-10T19:32:00.003+01:00

Hace tiempo que soy fan de Richard Monson-Haefel, que es el padre de muchas cosas, gurú de los EJB y del JMS y autor de varios libros de O'Reilly, de esos de tener en la cabecera de la cama.

Creo que desde el año 2000 sigo sus artículos en JGuru, en The Server Side, en Java.net..., he vivido sus aportaciones en revisiones de las especificaciones de EJB y en procesos JSR/JCP, y su participación en Geronimo, OpenEJB y finalmente Groovy...

En realidad viví de lejos su incursión en el mundo de plataformas RIA desde 2004 (me anclo en el pasado, hace ya 4 añitos que oficialmente dejó el mundo Java EE, aunque a seguido dando guerrilla desde entonces...), y ahora -aunque se veía venir- se ha pasado del todo al lado oscuro :-)

Ha decidido reenfocar su carrera profesional desde finales de 2008 hacia el muldo Multitouch, digo que se ha pasado al otro lado porque es un gran fan de Microsft Surfaces :-)

Valiente decisión para alguien que tenía a huevo aceptar uno de los múltiples y comodones puestos ejecutivos en grandes consultoras que le habían ofrecido, o dedicarse a ser conferenciante...

Gracias por todo, Clever monkey. Seguiremos tus evoluciones en ese giro de 180 grados que has dado... así que este post es un pequeño y muy humilde homenaje, por mucho que no me hayas aceptado todavía como amigo en el Facebook ;-)

Su blog, ahora reenfocado a la multitouch: http://theclevermonkey.blogspot.com/

Balanceo de cargas de EJB en un clúster Java EE. "Collocation Optimization" y cómo afecta al diseño de procesamiento BATCH de alto rendimiento

2009-01-30T19:02:00.011+01:00

Me gusta Java EE. Y me gustan los EJB. Siempre en su justa medida, me explico y no me fustiguéis los amantes de Spring Framework, que seguramente llevo más tiempo que vosotros en esto y las viejas costumbres son imposibles de cambiar...

To EJB or not to EJB

El concepto de componente empresarial (EJB) no es algo por lo que rasgarse las vestiduras, siempre que estemos hablando de Stateless Session Beans o Message-Driven Beans y no de Stateful Session Beans, o peor aún, de los infames Entity Beans (por muchas vueltas que le hubieran dado en la especificación 3.0 y lo que queda por dante con la 3.1 que se liberará este año...).

Lo de los Entity Beans es lo de siempre, mapeo O/R y por mucho que haya otras aproximaciones más potentes como Hibernate y similares, a mi lo que me gusta es tener el control. JDBC y SQL, tío. Que trabajar con SQL también es programar, y te aseguro que vas a tener menos problemas, la "magia" se termina pagando, en un proyecto es más el tiempo que se pierde en depurar las cosas raras de los mapeos O/R o conseguir optimizar una consulta o que haga un puto join de 8 tablas en lugar de 300 consultas a base de datos.

Pero me estoy yendo del asunto principal. Sigamos...

La historia de Java EE no empieza en J2EE sino en JPE, allá por 1998 (sorpresa, su primer nombre no fue J2EE). Y antes de eso, en 1997 salió la especificación EJB 1.0 y Servlet 1.0 allá porfinales de 1997:

Sí hay que agradecerle a Spring que haya conseguido poner las pilas a los chicos del JCP, ya que la especificación 3.0 importó algunos de los conceptos de Spring Framework, en concreto lo que respecta al uso de Anotaciones para eliminar los deployment descriptors y simplificar el carajal de desarrollar y mantener un componente, que los servidores de aplicaciones inyecten código en tiempo de despliegue/ejecución. También, desde algo antes, la 2.1, se permite definir interfaz local además de (o en lugar de) la remota, por lo que en tiempo de ejecución cada vez el tema es también más ligero, amén de que los fabricantes de servidores de aplicaciones compatibles cada vez hacen las cosas un poquito mejor...

No quiero hacer un alegato a favor de Java EE o en contra de Spring. Basta con decir que Spring, igual que Struts o Hibernate son lo que son, y estamos en manos de un sólo proveedor (o una sola comunidad pero visto lo visto con JBoss o con el propio Spring, tarde o temprano la gente quiere llevar las judías a casa, lógico). Y Java EE es una especificación con múltiples implementaciones, y no está en manos de lo que a Sun le apetezca hacer con sus cosas, sino que son "estándares" (JSRs) del Java Community Process (JCP), que por mucho que esté liderado por Sun (faltaría plus) no es lo mismo, amigo...

Por cierto, aparte de todo el miedo que ha habido en 2008 con el cambio de política de licencia y releases de Spring (ver artículo de Cmaj), también he oído voces que las nuevas versiones del susodicho cada vez son más complejas y pesadas. Oh, oh, ¿no era la comlejidad de Java EE y la simplicidad que deberían mantener las aplicaciones empresariales lo que hizo a Rod Johnson tirarse a crearlo allá por 2002?

Qué aporta el Contenedor de EJB

El concepto de EJB está ya maduro, pues, y el servidor de aplicaciones / contenedor de EJB provee dos servicios/características fundamentales que los hace muy atractivos:

Demarcación transaccional. Pudiendo definir el comportamiento transaccional de cada método de negocio de forma declarativa mediante anotaciones. Vamos, para los de antes, el contenedor de EJBs actúa como MONITOR TRANSACCIONAL.
Distribución. La interfaz remota de un EJB es un punto de potencial separación en múltiples instancias o servidores de aplicaciones. Es decir, además de otros mecanismos en la capa de Contenedor HTTP / Motor de servlets, ahí tenemos un punto de potencial balanceo de cargas y failover.

En realidad es lo único que me gusta del modelo. Pero no es poco.

Como decía, como todo, las cosas con mesura. Las dos penúltimas arquitecturas que diseñe para clientes se basaban en un único EJB fachada de toda la lógica distribuida en POJOs normales (o unos pocos EJB, para no mentir). Granularidad muy gruesa, amigo. Me gustan las ventajas pero la sobrecarga excesiva.

Balanceo de cargas y optimizaciones que dificultan las cosas

Pero hay una trampa, siempre hay truco. El balanceo de cargas / failover que nos proporciona un clúster de servidores de aplicaciones a nivel de EJB no es tan automático como parece, sino que puede llevar alguna sorpresa.

Y esto es debido a que está clarito-clarito que la arquitectura Java EE está pensado en el mundo online, orientado a peticiones remotas (de un navegador o de una aplicación remota) que requieren un procesamiento extrarápido y extraescalable. Lo cual hace que por defecto los servidores de aplicaciones se pasen por el forro de los cojones la distribución de cargas entre invocaciones de EJB. Es decir, si ya hemos balanceado en la capa http / servlet, ¿para qué volver a perder el tiempo en balancear la ejecución de cada componente involucrado en esa operativa si se da la premisa de que la sobrecarga de cada invocación remota (calcular_round-robin->serializar->enviar_por_la_red->deserializar->ejecutar->serializar->respuesta_por_la_red->deserializar) seguramente es más costosa que los milisegundos de ejecución de ese método de negocio?

Pues mejor no hacerlo. Y así es cómo actúan casi todos los servidores de aplicaciones cuando están en Clúster. al menos Weblogic, Glassfish y Websphere. E infiero que también el resto: si se invoca a un EJB desde dentro de un servidor de aplicaciones que está en clúster, el servidor de aplicaciones SIEMPRE invocará una instancia local del componente (que está desplegado en esa isntancia) y nunca a una de otro nodo del clúster. Es lo que se llama "optimización por colocación" que no es exactamente lo mismo que "afinidad de servidor".

A modo de ejemplo, pego un extracto de la documentación de Weblogic 10, que tiene su toque de ironía por cierto:

http://download.oracle.com/docs/cd/E11035_01/wls100/cluster/load_balancing.html
WebLogic Server always uses the local, collocated copy of Object A, rather than distributing the client’s calls to other replicas of Object A in the cluster. It is more efficient to use the local copy, because doing so avoids the network overhead of establishing peer connections to other servers in the cluster.
This optimization is often overlooked when planning WebLogic Server clusters. The collocation optimization is also frequently confusing for administrators or developers who expect or require load balancing on each method call. If your Web application is deployed to a single cluster, the collocation optimization overrides any load balancing logic inherent in the replica-aware stub.
If you require load balancing on each method call to a clustered object, see Recommended Multi-Tier Architecture for information about how to plan your WebLogic Server cluster accordingly.

Y, todo esto, son conclusiones para generalizar el comportamiento de los servidoresd e aplicaciones líderes del mercado, pero podría no ser así con el servidor de aplicaciones que hayas elegido...

Pero... ¿y la especificación EJB / Java EE no deja clarito estos comportamientos?

Pues lamentablemente no, curiosamente la especificación no dice absolutamente nada de cómo debe comportarse un clúster de servidores de aplicaciones. Bueno, miento, en realidad lo dan por sentado: los "contratos" que establece la especificación que deben cumplir los fabricantes de servidores de aplicaciones indican cómo debe esperar un diseñador/desarrollador que se comporte su aplicación y sus componentes. Pero en el alto nivel, nada de balanceo. Volvemos a lo mismo que decía antes con la magia del mapeo O/R o con las implicaciones del RMI/IIOP o con las curiosidades del protocolo HTTP: los pollos de las especificaciones piensan que un "desarrollador" no debe preocuparse por esas cosas. Pues mira por dónde, yo digo que sí.

Y también hay "zonas muertas" como si el EJB Timer Service debe disparar un trigger sólo en una instancia del clúster o en todas ellas (esto lo digo como curiosidad)...

En cualquier caso, créeme, lo que cuento arriba no es sólo válido para Weblogic, también para el resto, me juego una caña.

Procesamiento por lotes (en batch) de enormes volúmenes de datos

Leches, os diréis, ¿y esta chuminada en qué me afecta a mi? Si parece que es lo correcto ¿no?

Sí, en el 90% de los casos. Es decir, como digo en un procesamiento online normal así es. Pero ¿y qué hay de un peazo de proceso batch para tratar en chuncks millones de registros o hacer procesamientos computacionalmente complejos? ¿cómo beneficiarnos de las N máquinas del clúster en este tipo de procesamiento?

Pues, salvo que utilicemos aproximaciones menos transparentes (que desaconsejo), la única forma de hacerlo es que la clase que invoca al EJB esté fuera del clúster, en otro servidor de aplicaciones, o clúster administrativo separado.

Incluso en este caso, hay que tener cuidado porque en la misma URL de Weblogic que referencio, hablan de la "Transactional Collocation", es decir dentro de una misma transacción, si se invoca a métodos de negocio del mismo EJB aunque nos hayamos asegurado de que sea remoto... el muy cabrito invoca siempre a la misma instancia del clúster elegida en el round-robin para la primera invocación.

O sea, que la única forma de balanceo real y efectiva es que cada invocación a EJB esté en una transacción distinta (o que el método esté demarcado como REQUIRESNEW). Para un procesamiento batch basado en tratamientos de lotes (o chuncks) de información, esto nos sirve. Es decir, tenemos que procesar 20.000.000 de filas, y -por si lo estábais pensando- es una gilipollez intentar hacerlo en una sola transacción, de modo que la estrategia más ampliamente utilizada es hacerlo en "pequeñas" transacciones, cada una de ellas procesando por ejemplo 10.000 registros. Bien, en este escenario es perfectamente viable puesto que los requerimientos "de negocio" casualmente coinciden con las capacidades del clústering descrito. Siempre que el "master" o "controller" del proceso batch esté fuera del clúster donde se ejecutan los componentes de tratamiento de cada lote.

Últimamente me he hecho experto en procesamiento batch en Java EE. Que por cierto es casi un mundo virgen, qué curioso. Salvo por Quartz como único planificador medianamente serio (ejem si lo comparamos con TWS, anda que no nos queda...), y Spring Batch como único intento de framework para batches de alto rendimiento (aunque no lo recomiendo, sinceramente, aparte de que está muy-muy verde, tiene toda la pinta de que evoluciona hacia el Spring Integrator) con perdón del fantástico artículo High-volume Transaction Processing in J2EE, cuyas bases son impecables pero si tenemos cuidado con la paja mental que acabo de soltar y cuyo framework planteado pego a continuación:

Aunque, ya que estamos, si de verdad estamos hablando de procesamiento batch de eTL de grandes volúmenes de información, dejémosnos de Java EE y vayamos al siguiente nivel de abstracción, los Servidores de Integración (como Java CAPS, que incorpora un bonito módulo de eTL) o herramientas de eTL independientes. Aunque por cierto, en el caso de Java CAPS sospecho que el procesamiento "distribuido" de esas Collaborations de transformación no es tan distribuido, al fin y al cabo una Colaboración se implementa por debajo como un EJB, así que...

¿Y todo esto me afecta para algo o no?

Pues tú sabrás, tú eres el arquitecto :-)

En el 90% de las situaciones no, estáte tranquilo. Tú o tus compañeros de Sistemas Medios han diseñado seguro-seguro una arquitectura que balancea a nivel de motor de servlets, o mejor aún, pode delante de él, con balanceadors de cargas delante de los Apaches para las peticiones de los navegadores.

Pero en situaciones "no tan online" o en las que tu sistema hace procesamiento "de verdad" (y no las puñeteras aplicaciones de gestión que en realidad son las bancas online, comercios electrónicos y otras cosas que nos creemos que son muy avanzadas). O si tienes que precalcular informes estadísticos del último mes, o generar ficheros de extractos para ser descargados por todos tus clientes al día siguiente, no pretenderás hacerlo online ¿verdad? Y aunque la respuesta sea "sí", probablemente te gustaría no infrautilizar los flamantes N servidores que te han puesto ahí y cuyo balanceo "por delante" presupone que hay una homogeneidad en la duración y recursos consumidos por cada operativa o transacción...

También es cierto, que un buen particionamiento de los chunks es la base de un buen proceso batch, y que sólo son paralelizables tareas en las que hay más carga de CPU de tu servidor que de la base de datos que tienes por detrás. Porque como sea ese último caso, ya puedes paralelizar en Java, que el problema no lo tienes ahí... :-)

Pero el rollo de los particionamientos, chunks y otras aves sería motivo de otro artículo bien gordote... (para una introducción, lee el enlace que he referencio arriba, lo pego otra vez: http://www.devx.com/Java/Article/20791/0/page/1 )

P.D: Cada vez me cuesta más encontrar tiempo y fuerzas para escribir...

Historia de versiones del JDK y conceptos de rendimiento en Java

2009-01-02T00:43:00.000+01:00

Esta vez simplemente apunto unos enlaces a la Wikipedia.

Son muy-muy buenas recopilaciones aunque la entrada sobre "Java performance" está algo desactualizada y algunas de las optiomizaciones que marca como "futuras" ya están disponibles en Java 6u10 (y otras fueron introducidas en la 6u6-p.

Y no sólo son buenas referencias por su contenido en si mismo, sino porque la bibliografía a la que asimismo referencian es tremenda. Enhorabuena a sus autores:

YSlow

2008-12-26T11:24:00.000+01:00

http://developer.yahoo.com/yslow/

Complemento para Firebug que analiza las página según las best practices de rendimiento de sitios web del equipo Exceptional Performance de Yahoo.

webpagetest.org

2008-12-19T04:07:00.000+01:00

Me hago eco de esta reseña de la herramienta http://www.webpagetest.org/ que Martín hace en su blog.

No la he probado pero tiene muy buena pinta. Ahí está el artículo: http://brigomp.blogspot.com/2008/12/probando-el-rendimiento-de-pginas-web.html

highscalability.com

2008-12-14T10:44:00.001+01:00

Gracias a este post en el blog de Pensamientos Ágiles he descubierto uno de los mejores blogs/sites relacionados con la escalabilidad y cloud computing:

http://highscalability.com/

Artículos muy buenos y los enlaces también. Por cierto, muy chula la serie de artículos "Real Life Architectures", con notas acerca de la arquitectura de Amazon, Google, Flickr, Twitter, YouTube, eBay, Digg, MySpace...

P.D: Ya estoy viendo a mi amigo cmaJ haciendo palmas con las orejas por poder cotillear sobre estos grandes... ;-)

Eliminar ETags para incrementar el rendimiento

2008-12-09T21:20:00.002+01:00

Esto es algo que sigo sin entender, y que encima está por defecto en Apache: si para comprobar que es correcta la versión de un contenido que el navegador tiene cacheada se envía la cabecera "If-Modified-Since"... ¿por qué además existen los headers ETag en respuestas y posteriores If-None-Match en peticiones? (Nota para despistados: el ETag es como una especie de digest cutre del fichero).

Y para más coña, Apache lo genera por defecto a partir del INode, Fecha y Tamaño del fichero en cuestión. Desde mi punto de vista no aporta nada, consume recursos, obliga a enviar cabeceras innecesarias, y además puede dar "falsos negativos" en granjas o entornos balanceados o después de un despliegue de una aplicación (mismo fichero pero en otro inodo!).

iPlanet / Sun ONE Web Server (al menos hasta la versión 6.1) también lo pone por defecto y también se recomienda eliminarlo para mejorar el rendimiento.

Pero además, en Apache me he encontrado con otro problema: si está activado el mod_deflate para la compresión de contenidos, Apache nunca se da por enterado de que el fichero solicitado sí es el mismo que tiene el usuario en su cache, así que siempre devuelve un "200 OK" + todo el contenido, en lugar de un "304 Not Modified". Es porque al ETag enviado al cliente se le añade el sufijo "-gzip" al ETag, y es lo que el cliente envía de vuelta... pero por lo que sea Apache no es capaz de entender que el ETag con GZIP debería ser el mismo que el ETag sin GZIP. Es decir, da igual cómo se haya transportado el contenido, lo importante es si lo que hay en el servidor es lo mismo que tiene la caché del cliente ¿o no?

Bueno. ¿Y cómo se elimina? Afortunadamente de forma muy sencilla (para Apache):

FileETag None

Y para iPlanet 6.1 también es trivial:

<Object name="default"> (...) Output fn="set-variable" remove-srvhdrs="etag" </Object>

Para más información de por qué esto mejora el rendimiento:

Dejo por aquí también referencia al RFC de HTTP/1.1 en lo que a cabeceras se refiere. Cuántas veces he tirado de él y qué poco de moda está a día de hoy tener tiempo para leer RFCs, sino mejor buscar en blogs... ;-)

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Java Performance Community

2008-12-05T23:20:00.000+01:00

Tres enlaces de interés:

Performance group @ java.net: https://performance.dev.java.net/home/
General Performance Discussion @ java.net: http://forums.java.net/jive/forum.jspa?forumID=60&start=15
Performance tuning @ javapedia: http://wiki.java.net/bin/view/Javapedia/PerformanceTuning
Java Performance Tuning portal: http://www.javaperformancetuning.com/

Ahora sí: Java 6 update 11

2008-12-02T23:11:00.004+01:00

Pues unas horas después de la salida nula... ya está disponible el 6u11 en http://java.sun.com/javase/downloads/.

Como os comentaba, y podéis ver en las notas de la versión, incluye:

13 fixes de vulnerabilidades de seguridad.
18 fixes de otros bugs, sólo uno de Hotspot, y principalmente relacionados con los gráficos y el plugin (vamos, los grandes cambios de la 6u10 en ambos aspectos han generado alguna cagadilla)
16 fixes en VisualVM

Así que, parece que aunque la excusa de los updates impares son actualizaciones de seguridad, este en concreto lo han tenido que adelantar para arregar alguna cagadilla de la última release de hace 45 días.

Espero que la política de Sun no cambie hacia la "beta permanente" que está poniendo de moda Google y que amparamos bajo el nombre genérico de metodologías ágiles... y que tiene sentido en servicios/aplicaciones modelos SaaS... ¡pero no en esto, coño!

Salida nula: Java 6 Update 11 (6u11)

2008-12-02T14:57:00.000+01:00

Ummm...

Pues ha debido haber alguna "salida nula" en Sun o algún bug detectado a última hora, o alguien que ha tenido el dedo del gatillo demasiado rápido.

Porque en algún momento entre el día 1 y el 2 de diciembre (hoy) Sun ha liberado el Update 11 (6u11) del JDK/JRE pero a continuación lo han vuelto a eliminar de la página de descargas.

He visto la reseña en este post: http://blogs.sun.com/nbprofiler/entry/jdk_6_update_11_comes y efectivamente como indica alguno de los comentaristas si googleas "Java SE Development Kit (JDK) 6 Update 11" ya está indexado...

Como comentaba en la entrada Schedule de siguientes updates de Java 6. Versiones de Hotspot y compatibilidad entre ellas, se esperaba que este 6u11 sóo contuviera actualizaciones de seguridad pero por lo que parece incluye también al menos una actualización de VisualVM. Pero tiene que haber alguna actualización de seguridad porque si no, no se explica esta aceleración en el tiempo entre updates. ¿Menos de 2 meses? Ummm...

HOWTO: Importar un certificado servidor de Apache en un almacén JKS

2008-11-27T21:21:00.004+01:00

[Offtopic: Esta entrada no habla sobre rendimiento]

Si tenemos un servidor Apache configurado para atender por SSL con su certificado servidor y su clave privada, y queremos utilizar el mismo certificado servidor en una aplicación Java, ¿cómo hacerlo?

Usos: por ejemplo si queremos eliminar Apache como proxy inverso y que nuestro motor de servlets (Glassfish, Tomcat o lo que sea) sea el frontal web directamente, o si queremos utilizar el mismo certificado que tenemos en el Apache para otros propósitos como por ejemplo en un servidor FTPS hecho en Java (como Apache Mina) o cualquier otro servicio paralelo.

Para ello lo más sencillo es utilizar un PKCS#12 pivote, que luego podremos eliminar.

Comandos:

$ openssl pkcs12 -export -in <certificado.cert> -inkey <claveprivada.key> -out <pkcs12.p12> $ keytool -importkeystore -srckeystore <pkcs12.p12> -srcstoretype PKCS12 -destkeystore <almacen.jks> -deststoretype JKS

Obviamente, reemplazar <certificado.cert>, <claveprivada.key>, <pkcs12.p12> y <almacen.jks> por los nombres adecuados (ficheros origen utilizados por nuestro Apache, y JKS destino que se utilizará por nuestra aplicación Java).

Nota: la opción -importkeystore sólo es válida a partir de Java 6. En JDKs antiguos se utiliza "-import -pkcs12" (creo, pero tendría que tirar de archivo...)

Compatibilidad entre versiones de Hotspot y versiones del JDK

2008-11-23T14:25:00.003+01:00

Este es mi descubrimiento más curioso de todos en los últimos meses. Lo que en realidad me resulta curioso es no haberlo sabido/intuido hasta ahora. Es bueno estar siempre aprendiendo cosas nuevas, y es bueno también bajarse los humos uno mismo de vez en cuando...

Tradicionalmente muchos suelen confundir JDK y JVM. Pero son dos cosas distintas, una cosa es la versión de las bibliotecas Java, versión de bytecode y compilación javac (JDK) y otra muy distinta es la máquina virtual que ejecuta las aplicaciones Java. Esto lo he tenido claro siempre, lo que no sabía es que Hotspot tiene compatibilidad hacia atrás con versiones anteriores del JDK...

Con JRockit, esta diferenciación siempre ha estado muy clara, tanto por los usuarios como sobre todo por el equipo de JRockit/Bea/Oracle/quien_les_compre_a_continuación. Ellos distribuyen una versión de su VM "empaquetada" junto con una versión del JDK. De hecho, la versión JRockit 27.5 es compatible con JDK 1.4, JDK 1.5 y Java 6. Misma VM, diferente JDK en el paquete.

Pero estas semanas he estado haciendo pruebas y hablando con los ingenieros de Sun, resulta que Hotspot también es independiente del JDK y compatible hacia atrás con todos ellos (desde JDK 1.7 hasta JDK 1.5). En concreto he conseguido hacer funcionar con éxito y sin problemas aplicaciones sobre JDK 1.5 con Hotspot 14-b05 (distibuido en JDK 7 early access), y también el 6u6p con el mismo Hotspot 14 en lugar de el 13, que es el que venía por defecto...

¿Cómo se hace? Sencillo. Basta con identificar la bilioteca jvm de nuestro JRE y reemplazarla por la deseada. Algunos ejemplos:

En Windows, es el fichero jvm.dll que se encuentra tanto en <jre>\bin\server como en <jre>\bin\client (ojo, por supuesto que en realidad son distintas versiones, Hotspot cliente y Hotspot servidor)
En Linux x64, es el fichero libjvm.so que se encuentra en <jre>/lib/amd64/server

Del mismo modo, si no recuerdo mal, podemos poner la biblioteca jvm de JRockit en un directorio de instalación del JRE de Sun y viceversa. Es decir, la VM (Hotspot, JRockit, etc) es simplemente el libjvm.so si no me equivoco!

Lo que desde ya te puedo asegurar es que modificar la combinación JDK-JVM no está soportada por Sun. Así que, como suele decirse en estos casos... "Do it at your own risk!". Esto es lo que me dicen desde el equipo de Hotspot extraoficialmente cuando he preguntado por ello:

"Yes, for practical purposes, the latest HotSpot VMs should be compatible with JDKs back to 1.5, and we in engineering try hard to make that possible.

Sun, as a company, doesn't guarantee complete backward compatibility because of the huge testing matrix that would re required to verify each HotSpot release with every prior JDK. (We support more many more platforms than JRockit.)

So a customer can try out an new VM with an old JDK, but don't run your enterprise on it, and don't ask Sun to support it. ;-)"

:-)

Schedule de siguientes updates de Java 6. Versiones de Hotspot y compatibilidad entre ellas

2008-11-18T20:59:00.003+01:00

Como veis, estoy dosificando (demasiado) la información que he obtenido de mi interacción con el equipo de ingenieros de Hotspot en Sun, que ha sido muy interesante y emocionante al mismo tiempo.

Como diría un amigo mío, a mi edad y aún sigo emoocionándome con chorradas... :-)

Y creo que ahora estoy dando una primicia.

Ni que decir tiene que esta información es absolutamente extraoficial (aunque probablemente el calendaro previsto sea público a colaboradores, seguro que está por https://jdk6.dev.java.net/ pero no he tenido tiempo de chequearlo) y que el calendario final puede variar por muy distintos motivos. Tampoco aseguro que la información sea verídica, es la que me han pasado desde dentro, eso sí que lo aseguro...

Calendario previsto de siguientes updates de Java 6:

Java 6 update 10 (6u10 / 1.6.0_10): recién liberado el 15 de octubre, con la nueva microarquitectura
Java 6 update 11 (6u11 / 1.6.0_11): reservado para posibles actualizaciones de seguridad, puede que no se produzca si no es necesario
Java 6 update 12 (6u12 / 1.6.0_12): planificado para Febrero o Marzo de 2009
Java 6 update 13 (6u13 / 1.6.0_13): reservado para posibles actualizaciones de seguridad, puede que no se produzca si no es necesario
Java 6 update 14 (6u14 / 1.6.0_14): Planificado para Mayo o Junio de 2009

Correspondencia entre versiones de Hotspot y distribuciones de Java 6:

Hotspot 10: incluido desde Java 6u04 (con diferentes builds y fixes en sucesivos updates u05, u06 y u07).
Hotspot 11: ya incluido en Java 6u10.
Hotspot 12: ¿? creo que nunca se liberará, por mis noticias es una vía muerta.
Hotspot 13: fue incluido en Java 6u6p ("performance release") a modo de anticipo de futuras mejoras de rendimiento, pero tiene algunos bugs reconocidos como el que indiqué en el anterior post. Dudo que lo incluyan en 6u12, seguramente dará paso a Hotspot 14 directamente...
Hotspot 14: su build 05 está actualmente incluido en Java 7 (desde algun snapshot relativamente reciente, no recuerdo cuál) y está previsto su lanzamiento para entornos productivos con Java 6 Update 14 (6u14). Es posible que se libere en 6u12 si consiguen solucionar ciertos problemas de estabilidad que actualmente tienen, aunque lo más probable es que no sea así y tengamos esperar a mayo-junio pues...

O lo que es lo mismo, salvo que haya fixes de seguridad, tengo bastante claro que dejaré mis entornos de producción estables con 6u07 hasta junio (quizás actualice a 6u10 en enero). Y entonces migrar en los entornos de Pruebas y comenzar la certificación... o sea, que preveo que actualizaré Producción después de verano, dando el salto desde Java 6u7 a 6u14...

:-)

"What volatile means in Java" exposed by Jeremy Manson

2008-11-17T09:51:00.004+01:00

Para quienes no sepan de él, Jeremy Manson es una de las eminencias y referencias en el mundo de la concurrencia Java y en el modelo de memoria Java, de hecho, fue uno de los papás del "nuevo" modelo de memoria Java allá por 2004-2005. Curra en Google, lo cual dice algo sobre su nivel, y hay a quien se le hace el culo pepsicola con estas cosas... (por eso lo menciono :-) Y es un tipo excepcionalmente abierto y amable aun cuando sabe que no tienes razón en lo que le expones, podéis buscar mis interacciones con él en su blog :-)

Jeremy ya lo expuso bastante bien en sus anteriores posts (que yo referencié aquí), y en realidad este no da excesiva información adicional. Pero está bastante bien explicado y con algún gráfico que se agradece...

Así que no me enrollaré mucho más. Ahí van los enlaces a sus tres posts acerca de las variables volátiles en el modelo de memoria Java:

Y esta es una gran PPT sobre el modelo de memoria en Java, escrito por el propio Manson et al.:

http://www.inf.ethz.ch/personal/daniekro/classes/se-sem/ss2005/slides/sgier.pdf

P.D: He actualizado también el post de julio sobre double-checked-locking con esta información...

Uso de Apache como proxy inverso de Glassfish V2

2008-11-12T08:02:00.009+01:00

Aunque en muchos escenarios sería más que discutible... una práctica bastante habitual es tener un proxy inverso que sirva el contenido estático, haga balanceo y algunas reglas de seguridad delante de nuestro Glassfish.

Como digo es algo muy discutible en el 75% de los casos, la mayor parte de al gente lo hace como "buena práctica" y punto, pero no siempre hace falta y a cambio se complica un poquito más el sistema... Si se hace sólo por rendimiento, a día de hoy no tiene sentido porque Grizzly (el motor http de Glassfish) es muy óptimo y lo que se gana por un lado se pierde en las comunicaciones entre el proxy inverso y la aplicación final. Pero si se hace por seguridad (suele ser la excusa pero en la mayor parte de los escenarios no aporta nada, sobre todo si se ejecuta en la misma máquina que el Glassfish, je, je), o por balanceo de cargas o por caches, etc, etc. Entonces me callo. Sí que hace falta. Y es muy buena idea que sea Apache el servidor web escogido.

En cualquier caso. ¿Cómo hacer que un Apache 2 / 2.2 sea el frontal HTTP para nuestro Glassfish?

Espero que en V3 den soporte bien dado, para Glassfish V2 hay que hacerlo con mod_jk en el lado Apache y copiando unos jars de Tomcat 5.5 en el lado Glassfish. Sí lo habéis leído bien...

En todos estos enlaces están las instrucciones:

Pero, oh sorpresa, resulta que en los últimos meses las cosas han cambiado. Tomcat 6 no trae ningún tomcat_apj.jar (sino que lo han integrado en tomcat_coyote.jar) y la implementación en las versiones más recientes de Tomcat 5.5 no es compatible con Glassfish V2. ¿Te sale esta excepción al hacer una request?:

java.lang.NoSuchFieldError: USE_CUSTOM_STATUS_MSG_IN_HEADER at org.apache.jk.common.JkInputStream.appendHead JkInputStream.java:283) at org.apache.jk.core.MsgContext.action(MsgContext.java:267) at org.apache.coyote.Response.action(Response.java:221) at org.apache.coyote.Response.sendHeaders(Response.java:416) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:355) at org.apache.coyote.tomcat5.OutputBuffer.close(OutputBuffer.java:321) at org.apache.coyote.tomcat5.CoyoteResponse.finishResponse(CoyoteResponse.java:578) at org.apache.coyote.tomcat5.CoyoteAdapter.afterService(CoyoteAdapter.java:318)

Si esta es la excepción, esta es tu solución: coge el tomcat_apj.jar de Tomcat 5.5.23 y no de ninguna posterior (actualmente van por la 5.5.27 en la rama 5.5). Y funciona perfectamente.

Al César lo que es del César, a mi me ha salvado la vida esta entrada: http://www.albeesonline.com/blog/2008/10/10/javalangnosuchfielderror-use_custom_status_msg_in_header/

Todo una guarrada, ¿verdad? Lo cierto es que dice poco del equipo de diseño de Glassfish, es como si no hubieran pensado en implantaciones "para el mundo real"... ¿?

Identificación de bugs en la versión 6u6p y workaround

2008-11-08T01:18:00.003+01:00

Como indiqué en el post 6u6-p: Pues en Linux x64 peta!!!!!!!, en mis entornos servidor tuve problemas en la versión 6u6p. Tras enviar el feedback a Sun, los ingenieros del Hotspot se pusieron en contacto conmigo e hicimos múltiples pruebas.

El trato ha sido maravilloso, y estoy encantado de haber podido ayudar a identificar el problema, aunque he de decir que ya lo tenían resuelto, je je.

Tras varias semanas, por fin hemos llegado a la conclusión de que se trataba de un problema con el análisis de escape (ver para más información sobre Escape Analysis, ver los posts Allocation, deallocation and escape analysis for Java y ¿Funcionan las optimizaciones sobre el modelo de threading? ), que ya estaba identificado en el bug 6726999 y que han resuelto en la versión 14 de Hotspot, cuyo build 05 por cierto se distribuye con los Early Access del JDK 7 y que está previsto que se incorpore en Java 6 en un update aproximadamente en mayo-junio. Habrá que esperar pues...

He aprendido varias cosas de las interioridades de Hotspot y de versiones, pero tengo otros posts preparados para eso... De momento sólo diré que con el nuevo 6u10 por fin se distribuye Hotspot 11, pero el desarrollo del mismo ya va por la versión 14... Como podréis imaginaros, la evolución a nivel de Hotspot está siendo espectacular aunque tenemos que esperar para ver cada versión en la calle...

Me han pasado también varias versiones del libjvm.so, en concreto versiones "fastdebug" que tracean información de ejecución y compilación, y tiene además toneladas de asserts. Por ejemplo, algunos parámetros de lanzamiento interesantes para las VM fastdebug:

-XX:+LogCompilation: para escribir en un fichero hotspot.log y en el especificado arriba información acerca de la compilación binaria en tiempo real
-XX:SuppressErrorAt= (por ejemplo -XX:SuppressErrorAt=/xmlstream.cpp:119) para que no se ejecute un cierto assert

A lo que íbamos. Aparte de todo este rollo, el único workaround de momento, si se quiere funcionar con la 6u6p en producción es ejecutarlo con el parámetro de lanzamiento -XX:-DoEscapeAnalaysis. Yo no voy a hacerlo, prefiero seguir con Java 6u07 en producción pero con esa opción habilitada (porque ejecuto bastantes clases compiladas para JDK 1.4, aggg, y está lleno de StringBuffers, que se benefician bastante de los análisis de escape, aunque en Hotspot 10 estén hastante limitados de momento.

Además, dejo una perlita... en toda la interacción con el equipo de ingenieros de Hotspot, me han dado información extraoficial acerca de fechas previstas de liberación de las siguientes actualizaciones de Java 6 y sus correspondencias con versiones de Hotspot. Esto lo publicaré en el siguiente post...

:-)

Lanzamiento de Java 6u10

2008-11-03T05:06:00.003+01:00

[Actualizado el 6/11/2008: algunas correcciones y ampliación del resumen ejecutivo con mis conclusiones]

Sun liberó el pasado día 15 de octubre por fin Java 6 update 10 (6u10), que puede descargar como siempre de http://java.sun.com/javase/downloads/, tras mucho tiempo en beta y release candidate...

Nota: la noticia tiene ya 15 días, pero he preferido no escribir sobre ello hasta haberlo probado, claro :-)

Se trata de un hito importante (llevaban en beta bastante tiempo) porque supone una pequeña revolución tecnológica al menos para usos "de escritorio". De hecho, si os fijáis ha habido un salto entre el anterior update (6u07) y este (6u10), es debido a que se empezarons a librerar versiones beta más o menos a la vez que la 6u06, y dejaron margen a updates de seguridad por si se retrasaba más de lo esperado.

Pueden verse los detalles en:

Aquí mi resumen ejecutivo:

No se incluyen actualizaciones resoluciones de vulnerabilidades de seguridad. Por lo tanto la versión 6u7 está igual de actualizado que 6u10 en este aspecto.
Resolución de múltiples bugs, la mayoría afectando al uso de escritorio, entorno gráfico e instalación, pero algunos también son temas estrella en las versiones servidor, por ejemplo por fin han eliminado la limitación en el tamaño de heap por defecto a 1,4 GBytes en Windows x64 (se mantiene en Windows x32 por la limitación del espacio de direcciones a 2 gigas), además de corregir un memory leak con el modelo ParalellOlgGC de Garbage Collector (es el modelo paralelo que utilizo yo).
Se incorpora por fin la versión 11 de Hostpot, desde 6u4 se mantenía la versión Hotspot 10, con mejoras de rendimiento tanto para cliente como para servidor, además de resolución de bugs como los mencionados arriba
Nueva implementación del renderizado Direct3D para Windows, incluyendo (¡por fin!) aceleración hardware, aunque de momento sólo esté implementada para tarjetas ATI u nVidia).
Refactorización del JRE. El JRE ahora consta de un núcleo (kernel) mínimo y se instalan distintos bundles en función de las necesidades (ver documentación para más detalles).
Reingeniería del Plugin. Menudo revolcón le han dado, ya no es un pluggin "para apllets Java" sino que además integra las nuevas tecnologías JNLP y JavaFX. Importante: La gestión de applets tiene cambios significativos, incluyendo el tratamiento de applets no firmados, ver las release notes...
Y ¡por fin!, mejor control de versiones, elección de qué versión usar en caso de tener varias instaladas... y lo más importante de todo: la actualización puede funcionar en modo parche para no tener varios directorios con distintos updates del JDK instalado. Con lo molesto que era hasta hahora consolidar todo esto a mano. Por cierto que manda huevos que no lo hayan hecho hasta ahora.

Yo ya lo tengo instalado en mi PC, y funcionando con Netbeans y SQLDeveloper sin problema. Por cierto que he actualizado el post Tuning de NetBeans 6 (y NetBeans 6.1) para reflejar mi nueva configuración con aceleración gráfica por hardware, je je.

También lo hemos instalado ya en los entornos servidor de Desarrollo y Pruebas Integradas. Sin embargo, de momento no lo voy a instalar en los entornos de Preproducción y Producción hasta dejar pasar un tiempo y poder hacer pruebas de carga. En función de los calendarios que maneje de aquí a unos meses es posible que no tenga tiempo de certificarlo y, además, tengo noticias de primera mano "desde dentro" del equipo de Hotspot acerca del calendario de siguientes actualizaciones y versiones de Hotspot incluidas en ellas... pero eso es otra historia que escribiré en otro post ;-)

Fast InfoSet, Fast Web Services & XML encoding rules (XER) for ASN.1

2008-10-30T23:14:00.005+01:00

[Aviso para navegantes:

A diferencia del resto de temas, en los que hablo desde el conocimiento o experiencia (o al menos desde un cierto conocimiento, tampoco vamos a ponernos chulos), sobre este tema en concreto no tengo experiencia ni he podido hacer pruebas. Se trata de una línea de investigación que abrí hace algún tiempo y que no he tenido tiempo de cerrar u ocasión/excusa por concurrencia importante en accesos a Web Services de mi proyecto... ]

Curioso tema. Pongámosmos bíblicos...

Al principio era el COBOL. Las estructuras eran sencillas, fáciles y rápidas de parsear, los sistemas intercambiaban ficheros con campos de anchura fija. Y vio que era bueno...

Luego llegó el C y el C++, y empezó a requerirse optimización en los tamaños de los ficheros así como en el parseo. Y llegaron los mensajes con campos de tamaño variable en los que al comienzo de cada campo se indica la longitud del mismo. Existieron múltiples implementaciones, quizás la más estandarizada sea el ASN.1 (Abstract Syntax Notation One). Tremendamente rápidos de parsear y eficientes en espacio excepto si el contenido de los campos es de tamaño pequeño en media.

Luego llegó la era de Internet. De la interoperabilidad y de lo que mola. Y alguien inventó el XML que son mensajes estructurados donde los campos tienen delimitadores de inicio y de fin para ser parseados por aplicaciones pero legibles para el humano en base al éxito del HTML. Muy mono, muy manejable, muy entendible, pero muy ineficiente tanto en tamaño como en velocidad de parseo.

Vamos, que como el cangrejo. Vamos hacia atrás. No se "nota mucho" porque en paralelo se ha incrementado la potencia de procesamiento y la velocidad de las redes. Pero, cuando hay intercambio exhaustivo de mensajería o saturación del ancho de banda, la solución "elegante" puede no servir.

En este enlace se explica el problema de de forma más seria, pero en el fondo dicen lo mismo que yo... http://java.sun.com/developer/technicalArticles/WebServices/fastWS/:

(...)

XML-based messaging is at the heart of the current Web Services technology. XML's self-describing nature has significant advantages, but they come at the price of bandwidth and performance.

XML-based messages are larger and require more processing than existing protocols such as RMI, RMI/IIOP or CORBA/IIOP: data is represented inefficiently, and binding requires more computation. For example, an RMI service can perform an order of magnitude faster than an equivalent Web Service. Use of HTTP as the transport for Web Services messages is not a significant factor when compared to the binding of XML to programmatic objects.

Increased bandwidth usage affects both wired and wireless networks. Often the latter, e.g. mobile telephone networks, have bandwidth restrictions allotted for communication by a network device. In addition, larger messages increase the possibility of retransmission since the smaller the message, the less likely it will be corrupted when in the air.

Increased processing requirements affects network devices communicating using both types of networks (wired and wireless). A server may not be able to handle the throughput the 'network' demands of it. Mobile phone battery life may be reduced as a device uses more memory, performs more processing and spends more time transmitting information. As the scale of Web Services usage increases, these problems are likely to be exacerbated.

Y en esta línea, hace ya algunos años, se comenzaron dos iniciativas, lideró unas propuestas y especifcaciones llamadas "Fast Infoset" (trabajo conjunto entre ISO/IEC JTC 1 y ITU-T) y "Fast Web Services" (iniciativa de Sun Microsystems y también en proceso de estandarización por ambas organizaciones).

Muy resumidamente y en términos mundanos significa que los mensajes y estructuras se serializan codificados por debajo en estructuras binarias ASN.1, pero que el las partes (enviante y receptor) se tratar como si fuera XML normal y corriente. Es decir, en términos de capas OSI, los niveles de transporte y protocolo cambian, pero no cambia el nivel de aplicación.

Para los que quieran más detalles, sus números de estándar son:

ITU-T Rec. X.891 ISO/IEC 24824-1
ITU-T Rec. X.892 ISO/IEC 24824-2

Y, además de los enlaces que he incluido arriba (de Sun Microsystems), estas presentaciones son muy legibles:

Y estos dos enlaces también están muy bien escritos:

Y en este blog hay toda una catogría muy interesante al respecto...

http://blogs.sun.com/sandoz/category/Fast+Infoset

Desde mi punto de vista el tema en si mismo es para partirse de la risa (¿por qué hemos usado ASN.1 desde el principio y nos dejamos de tontadas?) y aparte, creo que esto soluciona sólo parte del problema (el transporte, aunque si usamos compresión GZIP ya ganamos bastante) pero no tiempo de computación y tratamiento. Amén de que dos no pelean si uno no quiere, es decir, ambos partners en el diálogo tienen que ser capaces de generar y entender estos Fast Web Services; si no, estamos jodidos...

Bueno, y ahora las implementaciones... Pues la buena noticia es que todo esto no es sólo teoría o desarrollos de difícil integración, sino que Sun tiene una implementación Open Source dentro del paraguas de Glassfish:

Programáticamente, como se explica en https://fi.dev.java.net/how-to-use.html
Por configuración general, añadiendo al domain.xml el parámetro -Dcom.sun.xml.ws.client.ContentNegotiaton=optimistic. Tengo que avisar, no obstante, que esta opción no la he encontrado en ninguna documentación oficial, sino en la presentación http://wiki.glassfish.java.net/attach/GlassFishDay2008Hyderabad/GlassFishDay2008PerfPreso.pdf que ya hemos nombrado alguna que otra vez.

Si tengo tiempo de probarlo, os aviso...

Pero no sólo de Sun vive el hombre... Al menos están estas tres implementaciones conocidas:

Raro, ¿verdad?

Tuning de NetBeans 7.x y 6.x

2008-10-23T15:33:00.007+02:00

[Actualizado el 27/4/2011].

Otro tip de rendimiento que no tiene que ver con el entorno de explotación, sino con el entorno de desarrollo. Mejoras de rendimiento de Netbeans 6/7 a través de opciones de arranque y otros factores...

¿Habéis probado a cambiar parámetros de lanzamiento del Netbeans? Pueden verse algunos tips recomendados por el propio equipo de Netbeans en:

Yo utilizo Java 6 update 25 y tocando algunas opciones de lanzamiento "interesantes" me va bastante-bastante bien en mi portátil con Centrino Duo. Aunque en realidad, mucho más importante que todo esto, lo que más me ha ayudado a aligerar el entorno es cambiar de disco duro a un híbrido con 4 GB de SDD y revolución a 7200 rmp (Seagate Momentus XT) así como desactivar todos los módulos y plugins que no se utilizan ni se van a utilizar, y tener cuidado de excluir las carpetas de proyectos de los scans antivirus.

El tema del escaneo constante de cambios en proyectos sigue siendo una pequeña pesadilla, pero estoy mitigándolo con las recomendaciones que en los enlaces anteriores se indican.

Mi fichero netbeans.conf contiene las siguientes opciones de lanzamiento:

###[serverperformance.blogspot.com] netbeans_default_options="-J-Dcom.sun.aas.installRoot=\"C:\Java\glassfish-v2ur2\" -J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=500m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J-Djava.index.useMemCache=true -J-Xverify:none -J-XX:+UseBiasedLocking -J-XX:+AggressiveOpts -J-Djava.net.preferIPv4Stack=true -J-Dsun.java2d.d3d=true -J-Dsun.java2d.noddraw=false -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true "

Rendimiento de la instalación de Java CAPS

2008-10-21T00:44:00.001+02:00

[Java CAPS 5.1.2 / Java CAPS 5.1.3]

Je, je, este no es un tip de rendimiento en tiempo de ejecución... sino un tip de rendimiento en tiempo de desarrollo, más bien en tiempo de instalación del repositorio y entorno de desarrollo...

De la documentación oficial de Sun:

3. Some optional but recommended performance enhancements:
Disable on-demand virus scanning on your Java CAPS installation directory. The large number of small files manipulated within the environment causes much unnecessary disk and CPU load if subject to constant scanning.
Set Internet Explorer’s cache size to 64Kb to improve the upload performance when uploading SAR files to the Repository. This is described in Microsoft’s Knowledge Base Article #329781

Aún con todo sigue siendo un infierno...

Tuning de motor de JSP en Glassfish: Configuración para entorno de producción

2008-10-14T21:26:00.010+02:00

Como continuación del post Glassfish V2: Performance Tuning, Tips & Tricks, a continuación pego algunos parámetros óptimos para entornos productivos en Glassfish V2. Recordad que Glassfish viene configurado por defecto "para desarrollo" y que pueden hacerse unos cuantos tunings para producción.

En el mencionado post están todos, amén de los parámetros generales de lanzamiento de las JVM que ya recomendé en el post JVM tuning: Parámetros de lanzamiento de JVM: Sun Hotspot.

Esta vez toca la configuración de nuestra aplicación web, en lo que concierne al motor de JSP. Los parámetros óptimos en mi experiencia y necesidades son:

[fichero sun-web.xml]:

(...) <jsp-config> <property name="development" value="false"> <description>If set to true, enables development mode, which allows JSP files to be checked for modification. Specify the frequency at which JSPs are checked using the modificationTestInterval property.</description> </property> <property name="usePrecompiled" value="true"> <description> If set to true, an accessed JSP ile is not compiled. Its precompiled servlet class is used instead. It is assumed that JSP files have been precompiled, and their corresponding servlet classes have been bundled in the web application’s WEB-INF/lib or WEB-INF/classes directory.</description> ¡¡¡OJO!!!! Si se pone a true, hay que compilarlos a mano con jspc y dejarlos en el directorio indicado. En nuestro caso, lo ponemos a false pero al desplegar la aplicación en el servidor de aplicaciones, marcamos el check "Precompile JSP" en la consola, para que se haga en ese momento... </description> </property> <property name="mappedfile" value="false"> <description>If set to true, generates static content with one print statement per input line, to ease debugging.</description> </property> <property name="suppressSmap" value="true"> <description>If set to true, generation of SMAP information for JSR 45 debugging is suppressed.</description> </property> <property name="fork" value="false"> <description>Specifies that Ant forks the compiling of JSP files, using a JVM machine separate from the one in which Tomcat is running.</description> </property> <property name="classdebuginfo" value="false"> <description>Specifies whether the generated Java servlets are compiled with the debug option set (-g for javac).</description> </property> <property name="xpoweredBy" value="false"> <description>If set to true, the X-Powered-By response header is added by the generated servlet. Buena idea para ocultar el AS por motivos de seguridad</description> </property> <property name="keepgenerated" value="true"> <description>If set to true, keeps the generated Java files. If false, deletes the Java files.</description> </property> </jsp-config> (...)

Ni que decir tiene que estos los fuerzo así porque sus valores por defecto son los contrarios. Para más información no seas vago y abre los PDF de la documentación...

Nota: me extrañaría mucho que estas mismas opciones no funcionaran "tal cual" en Tomcat 5.5 y superiores... Por cierto que todavía no me queda claro si GF tiene un Tomcat dentro, si está inspirado en Tomcat, o si simplemente han respetado las propiedades de configuración para eliminar resistencias al cambio... :-)

Cuidado con XA y JMS (o "Estoy hasta los huevos desde hace años")

2008-10-07T15:44:00.005+02:00

Pues lo de casi siempre:

...mucha capa de abstracción, mucha transparecia para el desarrollador y mucha magia... y a la hora de la verdad hay que remangarse y entenderlo todo.

Porque en Java CAPS las colaboraciones que interactúan dentro de un conectivity map en el fondo son MDBs. Y los MDBs en el fondo son EJB disparados por colas JMS. Y por defecto las transacciones JMS son XA, con dos cojones.

Es decir: si tengo unas cuantas colaboraciones (en Java CAPS, léase "unos cuantos EJBs" para una visión más generalista del mismo problema) que interactúan "desacopladamente" entre si (¡qué gran palabra! casi a la altura de "sinergia" y de "talento"...), o un master que va lanzando colaboraciones/MDBs de forma asíncrona o síncrona (request/reply), parece lógico pensar que todos los recursos a los que se accedan estén en modo XA... al menos, si no pensamos, los declaramos así :-)

Nota: el objetivo de este artículo no es explicar el patrón request/reply, pero ahí dejo un diagrama ilustrativo (enlaza con la explicación del patrón en docs.sun.com):
Ya primera gran mentira viene ahí, porque en el 99% de los casos no sólo accedemos a bases de datos sino que también escribimos en logs o en ficheros a disco, o interactuamos con un monitor transaccional o hacemos una petición http o TCP cruda... Llevo más de 6 años sin ver dónde está la magia del XA y viendo sólo dolores de cabeza, pero todo esto es otra cuestión...

...Lo que viene al caso para este artículo es que si en una colaboración Java CAPS (o en un MDB normal si funcionamos fuera de un integrador) invocamos a base de datos con transacciones XA y la invocación JMS a ese componente estaba también en modo XA, se produce un deadlock: como la inserción/modificación falla, el sistema decide deshacer también el envío a la cola JMS y por supuesto no llega nunca a enviar el mensaje de respuesta a la colaboración maestra indicándole el fallo (para que desde ahí se reaccione o lo que sea); en lugar de eso, la invocación al segundo componente vuelve a dispararse porque la cola estaba en modo XA. Y vuelve a fallar la inserción. Y así indefinidamente.

Esto que he explicado fatal está perfectamente explicado en el siguiente artículo: http://blogs.sun.com/fkieviet/entry/request_reply_from_an_ejb.

La solución: en modelos síncronos (request/reply) nunca usar modo XA para el envío del mensaje de request, sino ponerlo a modo TRANSACTED. Y ya que estamos, si sólo interactuamos con una instancia de base de datos, el recurso JNDI tampoco lo definamos en modo XA sino normal. Manténgase en modo XA sólo las invocaciones asíncronas de verdad y si queremos evitar posibles duplicados en inserciones. Pero mi apuesta es por no usar XA para nada y gestioanr las cosas a mano: porque teniendo el control, tendremos toda la capacidad de reacción con incidencias en el entorno productivo en lugar de liarnos a intentar modelizar mentalmente qué narices está pasando.

Porque además, en nuestro caso, hemos ganado un 50% de rendimiento en algunos pasos y el servidor de aplicaciones va mucho más ligero y con menos sobrecarga de recursos y cosas raras... (¿no iba este blog sobre rendimiento?).

Como digo, véase el artículo referenciado (no habla de Java CAPS en particular sino de EJB y JMS en general): http://blogs.sun.com/fkieviet/entry/request_reply_from_an_ejb.

Ciao ciao

Propuestas de optimizaciones para Strings

2008-10-01T15:26:00.011+02:00

Al hilo de lo comentado en los posts Copy-on-write optimization for StringBuilder and StringBuffer y Copy-on-write optimization for StringBuilder and StringBuffer (II), he estado trabajando más de la mitad del mes de septiembre (robándole tiempo a mi mujer, al sueño y a la tele por se orden) en una idea que yo pensaba que era cojonuda, aunque aviso de antemano que probablemente no sea buena, vistos los comentarios y estadísticas recogidas por mi... :-(

Por cierto, antes de seguir leyendo, si no estás familiarizado con cómo están implementados los StringBuilders y StringBuffer en el JDK, échale un vistazo a esos fuentes y al Java Language Specifications, porque si no esto pierde todo su encanto. En general es una buena práctica revisar cómo la gente del JDK ha hecho ciertas cosas, yo he aprendido de ellos mucho-mucho en los últimos 11 años... al menos demuestra algo de interés por el tema :-)

La nueva idea básicamente consiste en intentar ver la creación de Strings desde una perspectiva nueva: si el 95% de las operaciones sobre un StringBuilder son appends (y no inserts, deletes, etc), quizás eso nos puede dar una pista de reimplementación basada en almacenar la lista de cadenas que se quieren concatenar y sólo hacer la concatenación efectiva al invocar al método toString().

Desde el punto de vista teórico supone una ventaja importante frente al modelo actual de StringBuilder ya que no es necesario crear un array de chars interno, una vez llenado crear otro más grande y copiar los contenidos de uno a otro, y finalmente volver a hacer una creación de array de chars con el tamaño exacto y copia de los caracteres allí, en el toString().

Después de muchas vueltas y muchos intentos y benchmarkings, mi propuesta pasaba por crear una clase java.lang.StringAppender, que contiene internamente una lista de Strings...

El principal problema es con la inserción de un sólo carácter, operación que es tremendamente frecuente a la vista de las pruebas. Mi solución es entre un 5 y un 160% mejor al concatenar Strings, pero más de un 100% peor al concatenar chars individualmente. Como digo he probado otras combinaciones (almacenar char[][], almacenar dos listas, una para Strings y otra para chars, modificar StringBuilder para que pueda funcionar en "fast mode" y "normal mode" según interese... pero la opción más limpia y de mejor rendimiento en los casos que son típicos en un desarrollador de aplicaciones web (y que yo suponía que esto era extrapolable a cualquier otro desarrollo, incluyendo el del JDK, Netbeans, etc), es la que adjunto.

Pero no es suficiente, o al menos sería difícil de justificar el cambio de API (que es algo que no gusta mucho, evidentemente)...

En el archivo de la lista de correo de desarrollo de las librerías de núcleo para JDK 7 puede verse el detalle completo, las distintas respuestas públicas (también hubo unos cuantos consejos "privados"), y descargar el código fuente tanto en los cambios a String.java propuestos como la nueva clase StringAppender.java (nota: si hay interés en descargarlo, tómese la última versión publicada, no la primera)... así que no me enrollaré mucho más.

Ahí dejo el enlace al thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-September/000734.html. Y esta es la copia literal de mi primer y mi tercer mensaje que son un resumen ejecutivo de la idea, las estadísticas y las conclusiones.

El primer mensaje a la lista (http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-September/000734.html):

(...) This is my proposal to be discussed:

THE GOAL:
Boost the overall String concatenation / append operations.

BACKGROUND / HISTORY:
At the beginning (JDK 1.0 days) we had String.concat() and StringBuffer to build Strings. Both approaches had initially bad performance.
Starting at JDK 1.4 (I think), a share-on-copy strategy was introduced in StringBuffer. The performance gain was obvious, but increased the needed heap and in some cases produced some memory leak when reusing StringBuffer.
Starting at JDK 1.5, StringBuilder was introduced as the “unsyncronized version”, but also the copy-on-write optimization was undo, becoming an "always copy" scenario. Also, the String + operator is translated to StringBuilder.append() by javac. This has been discussed but no better alternative was found (seehttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959 ).
This current implementation generates several System.arraycopy() calls: at least one per append/insert/delete (two if expanding capacity)... and a final one in the toString() method!

STUDYING THE USES:
If we look at the uses of StringBuilder (both inside JDK code, in application servers and/or final applications), in nearly 99% of times it is only used to create a String in a single-threaded context and (the most important fact) only using the append() and toString() methods.
Also, only in 5% of the instantiatings, the coder establishes the initial capacity. Many times doesn’t matter, but other times it is impossible to guess it or calculate it. And even worst: some times the coder fails in his guess: establishes to much initial capacity or too few.

MY PROPOSAL:
Create a new class java.lang.StringAppender implements Appendable.
Mostly same in its exposed public constructors and methods than StringBuilder, but the only operations are the “append()” ones (no insert, no delete, no replace).
Internally represented as a String array.
Only arraycopy() or create char arrays once, inside the toString() method (well, this isn’t completely true: also arraycopies when appending objects/variables other than String instances or char arrays, but the most typical operation is appending strings!).
Doesn’t need to stablish an initial capacity. Never more calculating it or guessing it.
Add a new constructor in the java.lang.String class (actually 5 new constructors for performance reasons, see below):
public String(String... strs)
public String(String str0, String str1)
public String(String str0, String str1, String str2)
public String(String str0, String str1, String str2, String str3)
(NOTE: these 3 additional constructors are needed to boost appends of a small number of Strings, in which case the overload of creating the array and then looping inside is much greater than passing 2, 3 or 4 parameters in the constructor invocation).
Change the javac behavior: the String + operator must be translated into“new String(String...);” instead of into “new StringBuilder().append().append()... ..toString();”.
Revise other JDK sourcecodes to use StringAppender, and the rest of programs all around the world. (By the way in the Glassfish V2 sourcecode I see several String.concat() invocations; seems strange to me... ).
So the new blueprints for String concatenation should be:
For append-only, not conditional String concatenations, use the new String constructor. Example: String result = new String(part1, part2, part3,part4);
For append-only, conditional or looped concatenations, or for appending other Objects/types, use the StringAppender class.
For other manipulations (insert, delete, replace), use StringBuilder.
For a thread-safe version, use StringBuffer.

THE BOOST:
As you can see in my microbenchmark results, executed in Linux x64 and Windows 32 bits (-server, -client, and -XX:+AggressiveOpts versions), we can achieve a boost between 1% and 167% (depends on the scenario and architecture). Well, those values are the extremes, the typical gains go between 20% and 70%. I think these results are good enough to be taken intoconsideration :-)

THE SOURCE CODE:
See attachments, String.java.diff with the added code (it is clear), and StringAppender.java with the new proposed class.

THE MICROBENCHMARK CODE:
See attachment. Of course should be revised. I think I have made it correctly.

THE MICROBENCHMARK RESULTS (varied to me about +/-1% in different executions due to the host load or whatever):
See attached file. I think they are great...

What do you think?
Best regards,

Y este ha sido de momento :-) mi último mail de respuesta (http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-September/000747.html)...

Hi all.

I have measured the number of AbstractStringBuilder method invocations when executing NetBeans 6 (and making some work for 5 minutes) and when executing for a while a Glassfish V2 with a typical web application (Struts+Spring+Hibernate). These are the interesting and empirical results:

My conclusions:
The number of append(char) is bigger than append(String) and much bigger than other inserts (mainly in the Netbeans execution), so my StringAppender approach wouldn't perform good as predicted by Rémi and others. But the number of append(int), append(float), append(Boolean) is very low.
In a very few situations a Builder/Buffer is reutilized after calling toString().
expandCapacity() is invoked a lot of times!!!
Other operations (different than appends) are invoked a very few times.
So I suppose that my two proposals have few sense in general (haven't they?), but maybe these figures can help to reconsider the value of the default buffer length or can help others trying to make String/StringBuilder faster. Heap allocation and System.arraycopy calls must be reduced anyway!

P.S: Nevertheless I attach the "final" version of my modification to String.java and of StringAppender.java, which has some optimizations to append(char) but not sufficient... I think.

Best regards,

A mi personalmente me frustra la cantidad de alojamientos de heap y copias de arrays que podrían ser innecesarios en muchos casos, pero parece complejo encontrar una solución más eficiente... Bueno, en realidad tampoco es que se trate de un desastre absoluto porque afortunadamente los arraycopys están muy optimizados al menos en Solaris, Linux y Windows (me consta que ha habido mucho trabajao conjunto de los ingenieros de Sun con los de Intel y los de AMD)...

Y por otro lado la solución (sea la que sea) tiene que ser una solución "universal" en el sentido de que el código se migre mayoritariamente desde StringBuilder a StringAppender (o mejor, optimizando StringBuilder claro), como pasó en la migración masiva de StringBuffer a StringBuilder en los tiempos de la 1.5... o si no nuestro querido Hotspot puede decidir no compilar nativamente todos los sus métodos (qué asco, pero esa historia y lo chulos que son los compiladores nativos de verdad merece un post aparte).

Es decir, la mencionada nueva clase podría también crearse en Apache Commons o dentro de mis proyectos, pero si se usa millones de veces StringBuilder, malamente la JVM va a pensar que StringAppender tiene sus "hotspots"...

Por cierto que hay otras inciativas de optimizar las clases AbstractStringBuilder, StringBuilder y StringBuffer, pero van en otra línea más de inlinings y esos rollos. Y en alguna de ellas voy a echar una mano en pruebas microbenchmarkings, si sale algo positivo ya os contaré...

Y vosotros ¿qué opináis? ¿o soy yo el único que le ve interés a este asunto del rendimiento de los Strings????

:-)

Oracle: modo "Servidor Dedicado"

2008-09-26T05:51:00.001+02:00

Para los "listillos" en Oracle, como yo. Es decir aquellos que no somos DBA sino que nuestra experiencia se basa más en Java, pero que nos ha tocado alguna vez configurar Oracle.

Y claro, es un mundo. Y claro, las opciones aparentemente más lógicas no son las mejores.

En concreto me ha pasado con la configuración de Shared/Dedicated Server. En las instrucciones de creación de base de datos dice lo siguiente:

Modo Servidor Dedicado: "para cada conexión cliente la base de datos asignará un recurso exclusivo (...). Utilice este modo cuando el número total previsto de conexiones cliente sea pequeño o los cuando los clientes realicen solicitudes reiteradas y de larga duración a la base de datos. (...)"
Modo Servidor Compartido: "varias conexiones cliente comparten un pool de recursos (...). Utilice este modo cuando el número de usuarios que dan conectarse simultáneamente a la base de datos sea considerable a la vez que se utilizan eficazmente los recursos del sistema. (...)"

A priori, ¿cuál eligiríais? Pues no.

La cuestión es qué se considera "pequeño" en cuanto al número de conexiones. Y qué hardware tenemos. Y si el servidor Oracle compite por recursos con otros procesos importantes en la misma máquina. Y cómo se conectan las aplicaciones a la base de datos.

En resumidas cuentas, el modo compartido es un pool de conexiones. Pero nuestras aplicaciones (Java o lo que sea) ya gestionan las conexiones a través de uno o varios pooles por lo que lo único que estamos haciendo es anidar pooles. O lo que es lo mismo, en realidad en un escenario como el mío estoy tirando recursos y rendimiento a la basura. Cada shared server consume unos 20 megas de memoria adicional y, al fin y al cabo, termina abiendo conexiones reales dedicadas, claro.

Esquema del modo dedicado (Dedicated):

Esqueña del modo compartido (Shared Servers):

Por regla general podemos considerar que si vamos a tener menos de 500-600 sesiones abiertas y además hay pooles de conexiones en los servidores de aplicaciones cliente, se use el Modo Dedicado. En caso de un volumen mucho mayor el modo compartido.

¿Y cómo cambiar de un modo compartido a uno dedicado?. En Oracle 10g y superiores:

$ sqlplus system as sys dba SQL> alter system set processes=400 scope=spfile; SQL> alter system reset sessions scope=spfile; SQL> alter system set shared_servers=0 scope=spfile; SQL> alter system set max_shared_servers=0 scope=spfile; SQL> alter system reset dispatchers scope=spfile;

Donde dice "400", establézcase el valor que corresponda. Si no se establece valor para sessions, el sistema lo tomará de la siguiente fórmula: sessions = (processes * 1.1) + 5.

Puesto que estos valores son estáticos, debe reiniciarse la instancia para que tome su valor.

¿Y cómo se consultan los valores actuales?:

SQL> show parameter [parametro]

P.D: Para los que conocen el init.ora y no los SPFILES, las cosas han cambiado, ahora los parámetros se establecen a través de estos comandos de sistema...

6u6-p: Pues en Linux x64 peta!!!!!!!

2008-09-21T15:18:00.002+02:00

[Actualizado el 8/11/2008: El problema radica en un bug en el Escape Analisys, para más información ver Identificación de bugs en la versión 6u6p y workaround ]

Actualización al post Java SE 6u6-p Performance Release - YA DISPONIBLE EN OTRAS PLATAFORMAS:

Al lanzar Glassfish, mientras se despliegan mis aplicaciones (gordas eso sí), aproximadamente en el 70% de las ocasiones se me ha producido un core con un correspondiente fichero de err_.log. Lo curioso es que en el 30% restante de las veces ya no se cae, aunque pase pruebas de stress... Lo he probado tanto en CentOS 5.1 sobre un Supermicro como en un Redhat ES sobre un Sun Fire x64 y en ambos ocurre lo mismo.

He reportado la incidencia y los ingenieros de Sun están en contacto conmigo par resolverla... pero vamos, me ha dejado el asunto un poco frío porque en la propia web de Sun dice que la versión puede ser utilizada en producción y que puedes pedir soporte. Vamos, que en ningún momento tenía la sensación de que fuera a hacer de beta-tester, aunque lo hago bien a gusto. Digo esto como una crítica "suave", porque todos los del gremio estamos expuestos a estos fallos...

Pero nuestro gozo en un pozo de momento. Así que volvemos a la confortable versión 1.6.0_07...

Aceleradores hardware

2008-09-16T09:43:00.007+02:00

[Nota: en este artículo hago publicidad de marcas y modelos que conozco, sin otro ánimo que el ilustrativo y en ningún caso quiere decir que alternativas de la competencia sean peores opciones].

Actualizado el 19/9/2008

Con los avances en paralelización y multithreading de los últimos años (aunque con un cierto estancamiento de la velocidad por core), actualmente los responsables de servicios podemos adquirir servidores muy potentes a un coste relativamente bajo si lo comparamos con años anteriores. Ejemplos como Supermicro dan opciones muy económicas para entornos de "no tan misión crítica", pero fabricantes como HP e incluso Sun dan opciones x64 tremendamente interesantes (donde sube el precio es en el soporte).

En cualquier caso, hay situaciones que requieren "algo más". Y me explico. Si tenemos un entorno web de mucha concurrencia y computacionalmente "denso" puede ser que con un crecimiento horizontal en granja no sea suficiente. O mejor dicho, para mi gusto hay otras opciones que no requieren incrementar el número de máquinas.

Me estoy refiriendo a los aceleradores hardware. Los principales usos son la aceleración de SSL (operaciones de criptografía simétrica y asimétrica específicas para comunicaciones), HSM (operaciones criptográficas de propósito general) y GZIP (para la compresión de contenidos como se menciona en el post Compresión HTTP). He visto en una gran entidad financiera, con mis propios ojos, "morirse" un pedazo de servidor cuando hacía las operaciones SSL en los procesadores de propósito general, creedme.

Es cierto que muchos balanceadores y otros appliance de red nos solucionan parte de esta problática, pero en aquellos casos en los que esto no es una opción (o en los que precisamente lo que estamos construyendo es un appliance o proxy inverso) lo que debemos es adquirir los elementos hardware aceleradores adecuados. Hoy en día las opciones son mucho más económicas y mucho más potentes que lo que mucha gente se piensa.

Algunas opciones que hay en el mercado y que yo he tenido la oportunidad de probar (y poner en producción) son:

nFast SSL Offload (de nCipher): Tarjeta de red PCI (10/100/1000) que realiza las funciones criptográficas tanto asimétricas como simétricas (esta segunda parte es relativamente novedoso) necesarias para dar servicio SSL. Lo interesante de esta tarjeta es que actúa como un proxy inverso interno. Es decir, el interfaz de red atiende mediante canal SSL pero nuestro software servidores lo configuramos para que escuche "en plano", por lo que su integración es limpia e inmediata, y compatible con cualquier software.
- Rendimiento nominal: 10.000 transacciones SSL/TSL por segundo
- Throughput: 300 MBit/sec Full Duplex
AHA363 (de Comtech AHA): Tarjeta PCIe aceleradora GZIP, la más rápida del mercado. Trae una API y un módulo para Apache (aunque pueden desarrollarse otros.
- Throughput: 5 GBit/sec
nShield 500 F2 (de nCipher): HSM completo que implementa todos los algoritmos de criptografía simétrica y asimétrica (incluso curvas elípticas). No se trata sólo de acelerador sino que su uso principal es la securización de claves privadas. Dentro de toda la gama de velocidades y niveles de securización, esta es más que suficiente para la mayoría de los propósitos, pero hay otras muchas opciones.
- Rendimiento nominal: 500 firmas RSA de 1024 bits por segundo.

¿Os imagináis un sistema de servidores frontales x64 con dos procesadores XEON Quadcore y que además incorpore estas tarjetas? Imbatible. Y sorprendentemente económico, en órdenes de magnitud los elementos que he enumerado anteriormente rondan unos PVP de 3000€, 1000€ y 5000€ respectivamente. Es decir, obviando el HSM estaríamos aproximadamente duplicando el coste de un servidor promedio de las características mencionadas. Por unos 8000-9000 € tendríamos este sistema que aceptaría una concurrencia salvaje.

Obviamente tiene también sus inconvenientes, y es que cada elemento hard adicional incrementa las posibilidades de fallo, por lo que hay que considerar spare units y todo lo que conlleva.

Por cierto, respecto a la aceleradora GZIP no sólo estoy hablando de usarlo en la capa de servidor web / frontal, sino que fácilmente podríamos adaptar las bibliotecas Java o C de compresión para que en nuestra aplicación también utilizáramos el hardware de aceleración, e incluso hacer un JDK adaptado...

En algunos casos, en realidad, no hace falta irse tan lejos. ¿Sabíais que muchas de las capacidades de nuestros procesadores modernos están infrautilizadas? Para algunos propósitos no hay mejor acelerador hardware que el procesador que ya tenemos. Tanto AMD como Intel tienen bibliotecas de alto rendimiento para operaciones de copia de arrays, matemáticas, otras útiles para compresión, cifrado, procesamiento multimedia, etc).

Estoy hablando de Intel Integrated Performance Primitives (IPP) y de AMD Performance Library (APL). Un colega mío utiliza IPP para tratamiento de señales y asegura que es una auténtica maravilla, de hecho lo definió como "los ingenieros de Intel van 20 años por delante nuestro".

Una de las cosas con las que algunas veces he "soñado despierto" es con que las JVM/JDK puedan estar adaptados a estos aceleradores y también utilizar esas bibliotecas de Intel y AMD. Incluso llegué a mantener una conversación con Henrik Ståhl (Product Manager de JRockit en el momento de la conversación) preguntándole/proponiéndole sobre algunas de esas especializaciones. No lo veía claro y además los costes de mantenimiento sería brutal.

Por cierto que no soy el único que lo ha pensado, como puede verse en este hilo: http://forums.java.net/jive/thread.jspa?messageID=224530.

Pero volviendo al mundo real y asumible, os aseguro que el uso de aceleración SSL es una prioridad y la aceleración GZIP una auténtica necesidad si tenemos una concurrencia tremenda (¿cómo lo hará Google Inc.? ¿con aceleradores hard con los procesadores genéricos de las nubes de servidores?)

P.D.1: No he nombrado aceleradoras de gráficos, o el uso de las GPUs porque es un mundo que desconozco y que no he necesitado...

P.D.2: Sólo he nombrado esas marcas y modelos porque son los que yo conozco / he tenido experiencia satisfactoria. Hay otros fabricantes como http://www.safenet-inc.com/ o http://www.indranetworks.com/ con soluciones probablemente igual de válidas que las yo nombro arriba...

Actualización 19/9/2008: En otra conversación reciente con Henrik Ståhl, me sorprendió diciéndome que el uso de código / bibliotecas específicas para cierto hardware no es algo que hayan descartado para JRockit, aunque sea complicado. Digo que me sorprende porque en la primera conversación fue bastante tajante sobre los problemas que supondría y dudaba de los beneficios, sin embargo ahora ha dejado la puerta abierta. A mi ego le gusta pensar que he podido servir de empujoncito/inspiración...

Glassfish V2: Performance Tuning, Tips & Tricks

2008-09-10T21:48:00.004+02:00

[Nota octubre'08: Ver información complementaria en el post Tuning de motor de JSP en Glassfish: Configuración para entorno de producción ]

En la documentación oficial de Glassfish están bastante bien documentadas las opciones de rendimiento y optimización a varios niveles (a nivel de aplicación, de servidor de aplicaciones, de JVM y de parametrización de Sistemas Operativos):

Este blog contiene información general muy interesante sobre rendimiento de Glassfish:

Scott Oak's Blog

Y en esta presentación hay una relación clara y concisa de puntos de optimización en Glassfish:

http://wiki.glassfish.java.net/attach/GlassFishDay2008Hyderabad/GlassFishDay2008PerfPreso.pdf

Elementos que contiene esa presentación, con mis anotaciones personales entre corchetes:

Tuning

Tuning básico a nivel de JVM [nada nuevo]
Tuning del Web Container [ojo que por defecto hay pocos threads y conexiones keep-alive]
Tuning del EJB Container [idem con los tamaños de los pooles]
Tuning de la configuración en alta disponibilidad [nada nuevo]
Tuning de Web Services y parseo de XML en general [muy interesante el uso de Woodstox, aunque aún no por defecto, creo que la integración todavía es experimental]
Recomendaciones generales [incluyendo la precompilación de JSPs, y deshabilitar todos aquellos elementos que no vayan a usarse]

Best practices

... (mejor leer la PPT)

Es cierto que hay que tener mucho cuidado con tirar de PPTs en lugar de estudiar durante semanas, pero se agradecen este tipo de resúmenes ejecutivos, la verdad!

[Nota octubre'08: Ver información complementaria en el post Tuning de motor de JSP en Glassfish: Configuración para entorno de producción ]

Copy-on-write optimization for StringBuilder and StringBuffer (II)

2008-09-06T16:24:00.004+02:00

Continuación sobre Copy-on-write optimization for StringBuilder and StringBuffer.

Bien, parece que sí hay un bug en la Bug Database (no fui capaz de encontrarlo), y sobre el que se hizo un montón de investigación y pruebas, sobre JDK 1.5. Para más información, consultar http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959. Como se ve el bug se cerró como "Not fixed"a principios de 2006.

Las explicaciones para el cambio de estrategia de copy-on-write a always-write son, resumidamente:

Cuando se derivaban Strings desde StringBuffers en JDK 1.4, había un crecimiento importante en el consumo de memoria en los Strings. Si tengo un StringBuilder con tamaño de buffer N y el String final sólo ocupa N/2 posiciones, la estrategia de compartir el buffer hace que el String ocupe el doble de memoria de lo que debería, mientras que la nueva estrategia lo ajusta.
Aparte de esto, está el molesto tema de la inmutabilidad de los Strings. Si se hiciera mal uso de un StringBuilder (ojo, el problema no se daría en StringBuffer), podría darse el caso durante un pequeño lapso de tiempo de que de que un thread esté leyendo un String mientras que otro esté cambiando su contenido porque aún no se haya enterado de la compartición. Casi imposible en la práctica pero teóricamente posible, así que...

Queda el consuelo, leyendo la descripción del bug, de que los ingenieros de Sun pasaron muchas horas con el tema, que cualquier posibilidad que a mi se me iba ocurriendo ya la han considerado (gracioso, en el bug va diciendo "uno podría argumentar que...", "también podría pensarse en...", justo lo que yo había deliverado :-) ).

Y queda el consuelo de que tanto en el foro como el en bug se llega a la conclusión de que un escape analisis sería una solución válida para que Hotspot decidiera hacer la optimización cuando una regiiónd e código sólo es alcanzada por un thread a la vez. Otra cosa es si el esfuerzo merece la pena, claro...

Tengo una idea cojonuda en esta línea. Voy a darle unas vueltas y a proponerla. Tanto en este blog como en el foro de rendimiento.

Copy-on-write optimization for StringBuilder and StringBuffer

2008-09-05T00:41:00.007+02:00

Hoy he publicado mi primer post en el foro "General performance Discussion" @java.net:

http://forums.java.net/jive/thread.jspa?messageID=297309

Pego directamente (en inglés, me ha costado lo mío, je je):

Hello everybody.

The old 1.4 version of StringBuffer had a very nice implementation of a "copy-on-write" (COW), [as have the C++ String and the .NET StringBuilder, I think]. In few words: when the toString() method is called, it doesn't copy the char array to the String, but shares it with the String and marks as "shared" inside; and if there are future call to insert or remove or others in the "immutable" section of the char array, then creates a copy of the array and goes on (so the String keep immutable and the StringB can mute.

For some reason, this changed in JDK 1.5, becoming in a "always copy" strategy. Why? Haven't find it. I have only found the forum entry dated in 2005: http://forums.java.net/jive/thread.jspa?messageID=29032.

I don't understand what kind of concurrency problem that the COW approximation has. Can someone put the light on me?

For testing, I have hacked AbstractBuilder, StringBuilder and StringBuffer with the COW hack. And in a microbenchmark there is a significant boost in both cases, also NetBeans, Glassfish, my J2EE apps and so on worked great with this patch. Sorry but no deep multithreading testing...

Why not reintroducing it in JDK 7? No API changes, cheap change, and a good boost.

Salvo que tenga unos problemas rarísimos que mi corta mente no llega a alcanzar, no veo por qué no... al fin y al cabo StringBuilder es thread-unsafe de por si, y StringBuffer... bueno, si funcionaba el COW en versiones anteriores del JDK no veo la diferencia (a no ser que no fuera realmente thread-safe, claro :-)

Por espacio, no pego el código de AbstractBuilder, StringBuilder y StringBuffer que he tocado, es algo distinto al 1.4 pero el concepto es el mismo...

Hilos (para el que tenga interés en los detalles concretos, de momento podéis revisar ambos hilos):

http://forums.java.net/jive/thread.jspa?messageID=297309
También he puesto un comentario en el blog de Jeremy Manson, en la entrada Don't Use StringBuffer!

Actualización - 05/09/2008:
Parece más un problema de consumo de memoria que de sincronización. Entiendo perfectamente el tema (puede verse en la Bug Database, bugs 4259569, 4724129, 4524848, 4910256), pero es una auténtica pena por el acelerón que supondría. Así que en el foro he propuesto combinar esta opción con -XX:+AggressiveOpts. Seguremos informando...

¿Funcionan las optimizaciones sobre el modelo de threading?

2008-09-01T09:55:00.007+02:00

http://www.infoq.com/articles/java-threading-optimizations-p1

Interesantísimo artículo, que explica varias de las opciones de arranque de la JVM que yo recomendaba en el post JVM tuning: Parámetros de lanzamiento de JVM: Sun Hotspot, complementando así la información que publiqué en el post Allocation, deallocation and escape analysis for Java . Trata los siguientes conceptos:

Escape analysis - lock elision explained
Biased locking explained
Lock coarsening explained
Adaptive spinning explained

Adicionalmente presenta los resultados de un benchmarking hecho por él mismo probando combinaciones de varias de estas opciones y comparando el rendimiento de StringBuffer vs StringBuilder en ellas. Si la magia existiera, los tiempos del StringBuffer deberían tender a los del StringBuilder al aplicar todas las optimizaciones. Sus resultados:

Mis resultados en Linux x64 con 2xXEONx4Cores:

Son similares a estos en cuanto a los parámetros que más contribuyen al rendimiento y en cuanto a que "la magia no existe: usa versiones no sincronizadas de las clases!". Nota: las pruebas de rendimiento sobre varios núcleos y/o varios procesadores son muy distintas que en máquinas con un sólo núcleo, donde no hay contención entre threads "reales".
Curiosamente, en mis pruebas con distintas versiones del JDK (1.5, 1.6.0_07, 1.6.0_06-6p, y JRockit) he visto cómo el rendimiento en la "Performance Release 6" se ha incrementado drásticamente en el uso de StringBuilders frente a la edición "normal" de Java 6 (que por cieto es más lenta que JDK 1.5), pero no tanto de StringBuffers. Y también que los resultados de JRockit en ambos casos eran los mismos, es decir que JRockit sí que optimiza correctamente cuando no hay contención posible y Hotspot no del todo...

Es la guerra: IO vs "non blocking NIO"

2008-08-29T00:31:00.004+02:00

En esta entrada anterior hice una pequeña y somera referencia hacia que los procesadores multicore y el uso de NPTL y otras librerías de threads optimizadas, pueden haber cambiado las reglas del juego. Y no estar tan claro que la E/S no bloqueante merezca la pena frente a una IO bloqueante "de toda la vida".

Parece que a lo largo de 2008 se ha armado un pequeño revuelo / revolución a este respecto. Como muestra estos dos botones:

A favor de IO síncrona: http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html
Y la respuesta: http://weblogs.java.net/blog/sdo/archive/2008/04/more_on_the_sim.html

En definitiva, mi conclusión personal es la siguiente para máquinas de 8-32 cores:

Servidores con poca concurrencia esperada: IO síncrona
Servidores con concurrencia media esperada: IO síncrona
Servidores con concurrencia alta esperada: depende, habría que probarlo
Servidores con concurrencia brutal esperada: NIO asíncrona

En los escenarios 1 y 2, seguramente el problema de rendimiento y escalabilidad lo tengamos en otro sitio así que este no es un tema tan crítico en esos casos.

En cualquier caso, depende del uso y de lo que entendamos por poca o mucha concurrencia. El otro día un colega al que respeto un montón me comentaba que lo estamos viendo con un punto de vista exclusivamente de "contenidos de hipertexto"; en un entorno de servir contenidos multimedia el tiempo de cambio de contexto entre threads es inasumible de ninguna de las maneras.

Java SE 6u6-p Performance Release - YA DISPONIBLE EN OTRAS PLATAFORMAS

2008-08-24T20:23:00.006+02:00

[Notas de octubre'08 y noviembre'08 ==>

Querido googler: si llegas a esta página -como muchos- buscando información de las performance releases del JRE 6, quizás te interesen los artículos posteriores 6u6-p: Pues en Linux x64 peta!!!!!!! y Identificación de bugs en la versión 6u6p y workaround ]

En la entrada Java SE 6u6p Performance Release remarqué que en julio estaba ya disponible la versión 6u6-p Performance Release, pero sólo lo estaba para Solaris 64 bits.

Pues bien, por fin ya está disponible para un número más que interesante de otras plataformas, y la sopresa es que no sólo de 64 bits sino también algunas de 32 bits:

Ala, a rellenar el cuestionario en http://java.sun.com/javase/performance/survey.html y descargar, a ver qué tal...

Allocation, deallocation and escape analysis for Java

2008-08-20T22:57:00.009+02:00

Enlazo con este interesante artículo en IBM Developer Works:

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html (que es una addenda hecha en 2005 a este otro artículo de 2003 http://www.ibm.com/developerworks/java/library/j-jtp04223.html).
Y para información general acerca de qué es el Escape Analysis: http://en.wikipedia.org/wiki/Escape_analysis. Palabra de dios :-)

Básicamente el anterior post trata dos temas muy interesantes desde el punto de vista teórico:

El mínimo coste de la creación de objetos y reserva de memoria en Java frente a C/C++. Esto es gracias a la arquitectura interna con intervención del GC.
La inclusión del Escape Analysis en Java 6 y cómo eso beneficia al alojamiento de objetos en el stack frente al heap, lo cual puede ser una signfiicativa mejora de rendimiento...

Pues bien, el segundo de ellos parece que todavía no es cierto en Java 6 (el artículo es de 2005). Básicamente, hasta donde yo sé, sí que está implementado el análisis de escape (con la opción -XX:+DoEscapeAnalysis) pero sólo se usa para eliminar bloqueos, no para el alojamiento en stack. Quizás en Java 7 la optimización sea completa...

En este hilo puede verse la misma conclusión: http://forums.java.net/jive/thread.jspa?threadID=22617&tstart=120. Sin embargo en este otro post de 2007 se asegura que el Escape Analysis se eliminó de Mustang, por lo que me surge la duda si en actualizaciones posteriores sí se hizo o si simplemente es que hay desinformación por ahí... ver: http://blog.nirav.name/2007/02/escape-analysis-in-mustang-ii.html.

Y en cualquier caso con los microbenchmarks que yo he hecho (Linux, kernel 2.6, 8 cores) no parece que se gane mucho en cuanto a eliminación de locks, sí que parece suponer una mínima mejora pero nada comparable con el biased locking. Con todo el miedo que tengo a los microbenchmarks, en cualquier caso lo cierto es que la opción UseBiasedLocking está activada por defecto en Java 6, mientras que DoEscapeAnalysis hay que activarla.

El sentido común me dice que la decisión de poner opciones por defecto (o no ponerlas) por algo será (si partimos de la premisa de que los ingenieros de Sun no son imbéciles profundos ;-) y por lo tanto seguramente es un análisis experimental e imperfecto, así que tendremos que esperar a Java 7 para que ambas líneas de aprovechamiento del "análisis de escape" funcionen adecuadamente.

P.D: en otro post comentaré acerca del peligro de los microbenchmarks y cómo deben hacerse para no obtener resultados equivocados (en teoría, aunque tampoco me fío del todo).

[Actualización: puede verse información más detallada sobre esta y otras opciones de optimizaciones sobre el modelo de Threading en el post ¿Funcionan las optimizaciones sobre el modelo de threading?]

[Actualización 06-09-2008: Definición de Escape analysis en la Wikipedia: http://en.wikipedia.org/wiki/Escape_analysis]

[Actualización 04-11-2008: Conceptos generales de rendimiento en Java, incluyendo estos nombrados: http://en.wikipedia.org/wiki/Java_performance]

JVM tuning: Parámetros de lanzamiento de JVM: Sun Hotspot

2008-08-08T08:08:00.013+02:00

[Artículo actualizado el 3/11/2008 con información adicional sobre -XX:+DoEscapeAnalysis y -XX:+AggressiveOpts].

Parámetros de lanzamiento. JVM options. VM options. JDK option. Tuning parameter. Tunning.

O como queráis llamarlo. Por cierto que no se escribe Tunning, sino Tuning. a mi se me escapa mucho.

Sí, es tuning, pero no del de la foto :-)

La cuestión es de sobra comentada en este blog: cada vez el rendimiento sin tunear, o "Out-of-box performance" se aproxima más al mejor de los casos. Es decir en condiciones extremas puede haber una diferencia del 8% (que no es poco) pero puede ser un margen más que suficiente para no meterse en líos. Porque por toquitear podemos cagarla. Ahora o en un futuro. Pueden revisarse las reflexiones en la serie relacionada con la etiqueta Out-of-box.

A lo que vamos. Pero vale la pena intentarlo. Es más, casi diría que tenemos la obligación de intentarlo, cada aplicación es un mundo, los comportamientos de nuestros usuarios son otro mundo y las configuraciones y otros elementos para qué contarlo.

De todas formas, insisto en que no debe tunear por tunear, ni dejarse llevar por lo que supuesto expertos y teóricos aseguran en sus blogs (¿como este?). Las reglas de oro, en mi experiencia, son las siguientes:

No te fíes de la teoría. O de los expertillos de salón. O de "tu intuición e inteligencia". Ni mucho menos de la de tu jefe. Prueba tú mismo la inclusión de opciones nuevas.
No hagas Microbenchmarks. Mejor no hacerlos, puede llevar a conclusiones erróneas gracias a las optimizaciones (o no optimizaciones del Hotspot); aunque te creas más listo que nadie y pienses que lo estás simulando bien, lo más probable es que no sea así. Simula siempre con tu aplicación, no con un programita de esos que haces siempre para tomar tiempos.
Paso 1: No tuning. Out-of-box. Déjalo como está (sin configurar o preconfigurado para tu servidor de aplicaciones), tocando únicamente los targets de memoria en cuanto a heap y revisando que aparezca el -server (por ejemplo en Glassfish V2, el comilador es -client por defecto). Si el rendimiento en el entorno de ejecución es adecuado, incluso en situaciones de carga, no lo toques. Si funciona no lo toques.
Paso 2: Comienza a hacer pruebas de carga sobre tu sistema en pre-explotación. O en explotación. Pero pruebas de verdad, con un juego de pruebas coherente, con sus pausas aleatorias y la carga distribuida en distintos clientes con distintos anchos de banda simulado o real. Y ejecutado durante más de 2 horas cada uno. Lo mejor sería que las pruebas no fueran sintéticas 100% sino en base a los logs de ejecuciones pasadas, pausas, etc.
1. Parte de la configuración base. Toma los tiempos de referencia.
2. Sigue los pasos del apartado 4.2 del documento http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2. Empieza por el ejemplo 1. Aplica los parámetros y toma tiempos
3. Repite el paso anterior con los ejemplo 2..7. Toma tiempos de todo ellos.
4. Revisar las configuraciones de resultados publicados para los benchmarks del SPEC, y prueba con alguna de ellas (abajo pego un ejemplo).
5. Por supuesto hay otras miles de opciones, muchas indocumentadas lamentablemente. Si tienes tiempo, ya sabes. ¡A probar!
6. Toma tus propias conclusiones. Recuerda que un objetivo más importante que el rendimiento es la estabilidad al cabo del tiempo.
Menos es más (esto también lo dicen los chicos de Usabilidad). Si dos alternativas dan resultados casi equivalentes, opta por la que menos opciones de lanzamiento tenga.
Cada vez que cambies de versión de JDK, de versión de servidor de aplicaciones, de versión del kernel, o de hardware vuelve a hacer las comprobaciones, a no ser que en las notas de la versión dejen muy claro que sólo corrigen bugs que no te afectan. Apúntatelo en la cabecita. O en la libreta. O en la documentación. Un parámetro óptimo para una versión puede ser peor que la opción por defecto para la siguiente versión.

Dicho esto, y sabiendo que cada sistema y aplicación es un mundo, y los objetivos de negocio otro, voy a poner a continuación las opciones que a mi más mejor me funcionan.

Mi configuración HW y soft base, resumidamente es: máquinas x64, 2 procesadores XEON Quadcore (8 núcleos por máquina en total), 16 Gbytes de RAM, discos SAS en RAID 1, CentOS 5.1 kernel 2.6.18.
Viendo las configuraciones de resultados publicados en SPECjbb2005, una configuración que se repite con frecuencia es más o menos:
- Para Hotspot: -Xms3650m -Xmx3650m -Xmn2000m -server -XX:+UseBiasedLocking -XX:+AggressiveOpts -XX:+UseParallelOldGC -Xss128k -XX:+UseLargePages -Xbatch
- Para JRockit: -Xms3650m -Xmx3650m -Xns3000m -XXaggressive -XXlazyunlocking -Xlargepages -Xgc:genpar -XXtlasize:min=4k,preferred=1024k -XXcallprofiling

Lo que más me ha llamado la atención es que en casi ninguna configuración se abusa del tamaño de heap, aunque la JVM sea de 64bits en los tests no pasan de 3 GBytes de heap máximo. ¿Por qué? por tiempo de recolección de basura por supuesto. Esta puede ser una configuración válida para un benchmarking, pero en mi opinión es absurdo no aprovechar todo lo que nos da la máquina (o casi todo).

Los parámetros que mejores resultados me dan a mi en mi sistema y con mis circunstancias, y con estabilidad, son los siguientes, tanto en JDK 1.5 como en Java 6 (aunque en Java 6 algunas de ellas son valores ya por defecto): "

-server -Xmx12288m -Xms12288m -XX:MaxPermSize=256m -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy -XX:+UseBiasedLocking -XX:+EliminateLocks -XX:+AggressiveOpts -Xverify:none -Djava.net.preferIPv4Stack=true

"

De todo ello, lo más importante es elegir una buena estrategia de recolección de basura. En uno de los enlaces abajo están perfectamente explicadas todas las estrategias actuales, en mi caso el "stop-the-world" apenas se nota frente a una diferencia importante de rendimiento con estrategias concurrentes, quizás sea porque mi gráfico de objetos sea muy simple, un número medio de objetos con gran tamaño.

Un breve comentario de ellas:

-server: Entre otras diferencias con el modo cliente es el número de iteraciones antes de compilar una zona de código, 10000 frente a 1500. Se puede cambiar con la opción -XX:CompileThreshold, pero curiosamente mis pruebas han dado que un número ideal tiende a 7000-10000, indicando 0 o similar da resultados catastróficos... parece ser que por los inlinings y elecciones correctas, qué curioso. Nota: la opción -client puede ser la adecuada si lo que necesitas es buen tiempo de arranque o en situaciones en las que cambian mucho los JSP (cada JSP recompila a una nueva versión de la clase Servlet generada), pero algunas de las siguientes opciones no funcionarán.
-Xmx: tamaño máximo del heap, aún no tengo claro si incluye o no la zona de PermGen. Regla de oro: curiosamente la máquina donde se ejecutan JVM JAMÁS debe utilizar el swap a disco, la GC sería un desastre si tiene que ir moviendo páginas de un lado a otro.
-Xms: tamaño inicial del heap, en todos los sitios se recomienda igualarlo al máximo por rollos de fragmentación. Nota: esto no significa que el proceso consuma desde el principio esa cantidad de memoria física.
-XX:MaxPermSize: tamaño de la zona de generación permanente, donde nunca se hace GC (creo) ahí se alojan los objetos "clase" por ejemplo. Normalmente con 64 megas es más que suficiente pero si tienes muchos JSPs o muchos EJBs, mejor subirlo por si acaso (en Java CAPS por defecto es 192 megas).
-XX:+UseParallelOldGC: estrategia de máxima paralelización en la recolección de basura, no sólo usa múltples threads (por defecto tantos como threads reales máximos soporta tu máquina) en la recolección en las zonas jóvenes, sino también paraleliza la recolección en la zona antigua del heap. La opción por defecto con -server es UseParallelGC, en mi caso había una diferencia perceptible entre ambas. En muchos casos la opción adecuada debería ser -XX:+UseConcMarkSweepGC, en el que virtualmente no hay pausas perceptibles, pero el rendimiento global es menor. Por cierto, si vas al límite de consumo de heap o tienes algún memory leak, esta opción puede ser un desastre porque los tiempos de "stop de world" se hacen infinitos ya que no encuentra nada que liberar...
-XX:+UseAdaptiveSizePolicy: para no liarse con los tamaños de cada zona del heap, en mi caso lo mejor ha sido indicar este parámetro para que sea Hotspot quien vaya decidiendo y redimensionando por mi. Obviamente lo mejor es que no haya redimensiones y usar parámetros como -Xmn, -XX:NewRatio=2 y similares, pero hay que tener mucho cuidado porque pueden empezar a saltar OutOfMemory's cuando no deberían...
-XX:+AggressiveOpts: ~~Aplica (si las hay) optimizaciones experimentales que se liberarán oficialmente en siguientes versiones del JDK.~~Habilita aquellas opciones de rendimiento que se prevén como habilitadas por defecto en siguientes releases del Hotspot, es decir muchas de las que explícitamente se especifican a continuación en realidad no es necesario indicarlas si aparece esta opción. Yo lo he usado siempre y nunca ha habido un comportamiento raro. En mi caso sí que aportaba un 1-2% de mejora sin afectar a la estabilidad, si no es el caso mejor no ponerlo por si acaso.
-XX:+UseBiasedLocking: Utiliza una estrategia de bloqueo que beneficia escenarios en los que sólo un thread pasa por una región de exclusión mutua (reduce la "contención") pero penaliza algunas estrategias de bloqueo. Teniendo en cuenta que la mitad del JDK está sincronizado y que no suele unsarse un String o un ByteArray desde dos threads concurrentes, es una gran idea. En Java 6 está habilitado por defecto, en JDK 1.5 hay que habilitarlo o especificar +AggresiveOpts.
-XX:+EliminateLocks: Otra técnica de optimización que se nota levemente, básicamente unifica regiones de exclusión mutua en un mismo thread. Una vez más el diseño de las clases del JDk hace que esta estrategia sea beneficiosa. Creo que no está habilitado por defecto en Java 6, salvo que especifiques +AggresiveOpts.
-Xverify:none: no verifica todas las clases contenidas en el bootclasspath y resto de cargas(ncluyendo el escaneo de todos los JARs) al arrancar. Acelera la fase de lanzamiento pero más vale ir con ojo porque está deshabilitando un control que mejor activar tras un par de semanas de funcionamiento. Cuidado por tanto con deshabilitar a la ligera la verificación si desplegamos código no confiable o de proveedores externos en nuestros servidores de aplicaciones, ya que esto puede derivar en alguna vulnerabilidad.
-Djava.net.preferIPv4Stack=true: Bueno, básicamente que no utilice el stack de IPv6 para el networking. Si no usas IPv6, activa esta opción y verás...
[-XX:+DoEscapeAnalysis: Esta es una opción que no está en JDK 1.5 y sí en Java 6 y JDK 7, en mis microbenckmarks daba peores resultados que desactivándolo curiosamente, aunque la teoría dice que debería funcionar para eliminar locks en regiones por las que sólo puede pasar un thread a la vez] NOTA DE REVISIÓN DE 3/11/2008: esta opción se habilita al establecer +AggresiveOpts, por lo que los microbenchmarks habría que revisarlos, porque los benchmars reales dan mejor resultado con +AggresiveOpts que sin ella.
[Otras opciones como -XX:+UseFastAccessorMethods y -XX:+StringCache no las he probado explícitamente. Al menos el primero de ellos creo que stá habilitado por defecto en todas las VM, y el segundo no lo tengo claro pero estoy casi convencido de que se ve afectado por +AggresiveOpts.]

Insisto, lo mejor es dejar el máximo número de opciones a su valor por defecto, aunque a todos nos gusta tunear. Y no te fies de los blogs. ¡Ni de este! Prueba, prueba y prueba

Ver algunas explicaciones y enlaces de interés en:

P.D: Empiezan los Juegos. Que gane el mejor y que nadie se ahogue entre la polución de Pekín...

Comparativa de rendimiento en la lectura de ficheros

2008-07-28T06:01:00.003+02:00

A vueltas con el rendimiento en I/O :-)

Este artículo y comparación es tremendamente interesante, sobre todo porque está documentado con datos de benchmarking aunque sobre un hardware particular, ojo. Las conclusiones son las de "casi siempre", pero para un tío oxidado como yo está bien que se meta la NIO entre las comparaciones. Y que se compare con C, que sigue ganando, je je.

Sólo pegaré aquí las conclusiones, el resto debe leerse en el artículo original:

How read files quickly

For the best Java read performance, there are four things to
remember:

Minimize I/O operations by reading an array at a time, not a byte
at a time. An 8Kbyte array is a good size.
Minimize method calls by getting
data an array at a time, not a byte at a time. Use array indexing to get at
bytes in the array.
Minimize thread synchronization locks if you don't need
thread safety. Either make fewer method calls to a thread-safe class, or use a
non-thread-safe class like FileChannel and MappedByteBuffer.
Minimize data
copying between the JVM/OS, internal buffers, and application arrays. Use
FileChannel with memory mapping, or a direct or wrapped array ByteBuffer.

Si tuviera tiempo, me gustaría compararlo con una la versión "no sincornizada" de BufferedInputStream, para ver el impacto que en concreto introducen las regiones de exclusión mutua.

Ubicación original del artículo: http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly

Java CAPS: Optimización de transmisiones de ficheros

2008-07-23T05:40:00.002+02:00

Java CAPS es el acrónimo de "Java Composite Aplications Platform Suite". Es la suite completa de Sun aunando Integrador + ESB + EAI + BPEL PM + eTL + B2B. En realidad muchos de estos conceptos se difuminan unos con otros según quién los defina, así que es lógico que estén en una sola plataforma, aunque una organización tienda a usar sólo el 20-50% de su capacidad y potencia.

Y forma parte del Java Enterprise System, pero como producto independiente. y no es barato precisamente. Muy potente, pero muy desesperante muchas veces. Como sus competidores (Aqualogic, por ejemplo).

Como cualquier framework o integrador termendamente potente y tremendamente flexible, en muchos aspectos se ahorra tiempo de integración (con SAP, con SWIFT, con host, con MQ, con HL7......) y sobre todo de mantenimiento posterior, pero a cambio no esperemos el mejor rendimiento y tener el máximo control a bajo nivel. Toneladas de capas de encapsulación lo impiden.

Como otros entornos, Java CAPS es de esos que te permite hacer las cosas mal y bien. Y por defecto, la opción rápida es hacerlas mal. Y la opción "no inmediata" es hacerlas bien. Es decir, leches, todo en memoria.

Y por duplicado muchas veces. Para variar.

Este artículo habla de cómo implementar comunicaciones FTP/FTPS/SFTP de forma "optimizada" para ficheros enormes. Sin más comentarios:

http://blogs.sun.com/javacapsfieldtech/entry/streaming_large_ftp_transfers_with

Más información sobre Java CAPS en la web oficial de Sun:

http://www.sun.com/software/javaenterprisesystem/javacaps/index.jsp

Oracle JRockit: malas noticias, se confirman las sospechas

2008-07-19T19:27:00.019+02:00

(Actualizado el día 21 de julio y también el 19 de septiembre)

Aquí está la noticia esperada, aunque no por ello menos horrible para la comunidad. Léase detenidamente, no obstante el resumen ejecutivo es que JRockit no va a ser un producto independiente, sino que estará incluido en los paquetes y productos comerciales de Oracle (Weblogics, Fussions, y otros).

http://www.oracle.com/technology/software/products/jrockit/FAQ.html

Puntos más significativos:

Sólo los clientes de Oracle lo pueden utilizar en producción (no sé si incluye la base de datos o sólo los productos de App Server / SOA).
Eso sí, puedes usar ese JRockit licenciado para ejecutar otros productos / servidores de aplicaciones que no sean de Oracle.
Desaparece la "redistributable license" para las nuevas versiones de JRockit. Vamos que no puedes empaquetar tus productos con JRockit incluido.
Sí sigue siendo gratuito y descargable (http://www.oracle.com/technology/software/products/jrockit/index.html) para desarrollo y evaluación.

Es cierto que era una decisión previsible, conociendo la política comercial de Oracle. Y por otro lado es cierto que es discutible el beneficio en términos marketinianos y de posicionamiento de marca que implica tener un producto gratuito sobre el que dedicas toneladas de recursos internos de la compañía... ante eso hay dos posibilidades:

Abrir el producto para dedicar menos recursos a él y simbiosis con la comunidad "open Source"en esa misma. Es lo que ha hecho Sun con OpenJDK 7 (es discultible la tibieza de esta política, pero bueno).
Cobrar por el producto o incluirlo en otros productos comerciales. Es lo que ha hecho Oracle.

Vamos, y haciendo de "oráculo" ("Oracle" en inglés si se me permite el chiste fácil): R.I.P y también supondrá a largo plazo un frenazo a las mejoras en Hotspot, a no ser que se ponga las pilas la comunidad Open Source...

Como puede verse, a nivel personal estoy contrariado, porque creo que básicamente esto elimina la competencia que había "entre los dos grandes" que ya comentamos en http://serverperformance.blogspot.com/2008/06/sun-hotspot-vs-bea-jrockit.html. Bueno, quizás IBM vuelva a recoger el guante pero lo dudo porque su política actual es un híbrido: JDK sin limitaciones para Linux, AIX y z/OS, pero en Windows sólo está disponible el JRE y sólo para máquinas IBM -controlado en BIOS- excepto un par de licencias para tests con Eclipse y para Apache Harmony... Para más información ver http://www.ibm.com/developerworks/java/jdk/.

En fin, tampoco gritemos esto muy alto porque los resultados empresariales de Sun en este semestre han sido horribles y hay rumores sobre el descontento de los accionistas sobre la política de "software gratis significa beneficios con el hardware" y quizás vientos de cambio que vete a saber...

Corolario: Al final va a resultar que la recomendación que hice en la entrada enlazada arriba ("(...) mi opinión es que hoy en día hay que ser pragmático: si vas a ejecutar un Weblogic / Aqualogic, móntalo sobre JRockit; y si vas a ejecutar un Glassfish / JES / Java CAPS, hazlo sobre la JVM de Sun.") va a dejar de ser una recomendación sino una obligación, un mapa oficial de dependencias entre productos, licencias y hardware/software base. Es decir, habrá un par de JDKs abiertos y libres (Open JDK por un lado y Apache Harmony por el otro) y después cada sistema operativo y/o servidor de aplicaciones tendrá asociado un JDK específico de ese mismo fabricante. Y en realidad de facto ya es ese el panorama como hablábamos, véase los JDK de HP e IBM específicos para para ciertos sistemas operativos, y los JDK específicos para ciertos servidores de aplicaciones. Sólo falta que Sun tenga dos versiones de su JDK et voilà..

Aclaración: Ojo que no soy ningún fan de Sun ni mucho menos, pero mira por lo menos me acaban de ahorrar tiempo para tomar cierta decisión...

P.D: Y otro chiste fácil y viejo... "ORACLE" al revés se lee "EL CARO" :-) [For those using automatic translators: this is a pun in Spanish: "O-R-A-C-L-E" => "E-L-C-A-R-O", meaning "THE EXPENSIVE ONE"]

Actualización 19/9/2008: Unos meses después, parece que las aguas han vuelto a su cauce y se ha normalizado la política de Oracle respecto a los productos de Bea, al menos vuelve a haber blogs corporativos y la gente de JRockit parece activa y trabajando en distintas líneas nuevas...

Buffers inteligentes con swap a disco, o "a prueba de tontos"

2008-07-14T06:49:00.006+02:00

Entramos en modo paja mental, siguiendo lo que introduje en la anterior entrada "Buffers: por defecto y por exceso".

De forma recurrente, vienen a mi dos necesidades / problemas típicos, que pueden resolverse de forma elegante a la vez. Dos por uno. Mierda para cada uno.

A saber:

Dado un OutputStream sobre el que mi código va escribiendo quiero ser capaz de obtener de forma elegante el InputStream. Sin mucha sintaxis, sin crear programáticamente ficheros temporales o hacer cosas raras con arrays de bytes. Ni con extraños modelos de pipelining. Pensando en un uso single-thread. ¿Por qué? Porque yo lo valgo. Y porque Murphy dice que si tienes un OutputStream invocarás a un método que necesite como parámetro un InputStream. Y viceversa.
Y mucho más importante: ¿cuántas veces hemos dicho lo malos malísimos que son los arrays de bytes? ¿es que no somos conscientes de que potencialmetne son un cúmulo de bichos? ¿que se volverán contra nosotros en cualquier momento del futuro, cuando estamos pensando ya en otras cosas?

Es inimaginable cómo se abusa en general del uso de array de bytes. Y no me refiero sólo a los típicos gazapos de un programador que empieza. Me estoy refiriendo a diseños internos de productos de reconocido prestigio tanto a nivel nacional o internacional (y no señalaré a nadie).

En alguna otra ocasión hemos hablado de que sería maravilloso que la gestión de memoria en Java soportara algún tipo de nuevo modelo de memoria, separada de los heaps y permgens y todo eso, sobre el que pudiera hacerse swap a disco sin problema. Sé que ya es suficientemente compleja (eden, survivor space, permanent) pero sería genial que la propia JVM detecte el uso de arrays / buffers grandes, o que fuera configurable, y que permitiera hacer swapping a disco de todo o parte de él independientemente de en qué zona de memoria resida.

Pero mientras no sea así, también podemos hacerlo nosotros. La encapsulación al poder. Dejo aquí un código fuente que hice en 2003, allá por los tiempos del JDK 1.3 y 1.4 (creo :-), que básicamene encapsula eso: funciona como un ByteArrayOutputStream de esos que gustan tanto a los programadores, pero en cuanto pasa de un cierto tamaño máximo, swapea a disco. Y además permite recoger un InputStream para hacer pipelines dentro de un solo thread. Por cierto, sin regiones de exclusión mutua porque está pensado para ser usado en un solo thread.

Es decir, un mecanismo "automático" para balancear alto rendimiento y alta escalabilidad: rendimiento en el tratamiento de streams cuando estos son de un tamaño aceptable (todo en memoria), y escalabilidad porque limita el abuso de la memoria como recurso en caso de que algún elemento se nos vaya de las manos.

¿Usos? Más de los que pueden parecer en un principio, por ejemplo intercambio de información entre procesos/colaboraciones desacopladas, para tratar optimizadamente peticiones SOAP con grandes ficheros como parámetros, generación y tratamiento de imágenes o PDFs o Excels en servidor, uso como elemento temporal "optimizado" por ejemplo en un GZIPFilter (si el tamaño comprimido es pequeño, se usa buffer en memoria, si es grande se usa buffer en disco para no consumir excesiva), etc.

Ahí va el código fuente:

package org.serverperformance.io; import java.io.File; import java.io.BufferedInputStream; import java.io.ByteArrayInputStream; import java.io.OutputStream; import java.io.InputStream; import java.io.IOException; import java.io.FileInputStream; import java.io.FileOutputStream; /** * Equivale a un ByteArrayOutputStream con las siguientes características especiales: * - El buffer sólo consume 32 KBytes de heap (configurable, en caso de requerir más, * utiliza el disco per nunca consume más heap que el marcado. * - Métodos getInputStream() y writeTo(OutputStream) para facilitar las * conversiones (típico al invocar métodos de JDBC que requieren InputStreams, mientras * que la información se va escribiendo en un OutputStream * - Se añade un método write(InputStream) que escribe en este stream de salida todo el * contenido del stream de entrada. * - A diferencia que ByteArrayOutputStream, el método close() también libera recursos en memoria. * * El código fuente está basado en java.io.BufferedOutputStream, con los añadidos * necesarios y quitando las regiones de exclusión mutua. * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com * @version 1.1, 30/06/03 */ public class IntelligentBufferedOutputStream extends OutputStream { private final static int DEFAULT_BUFFER_SIZE = 32*1024; private final static String TEMP_FILE_PREFIX = "temp_buff_serverperformance_"; private final static String TEMP_FILE_SUFFIX = ".tmp"; /** * The output stream to the underlying temp file. */ protected OutputStream out; protected InputStream in; /** * The underlying temporal file. */ protected File tempFile; protected boolean usedTempFile = false; /** * The internal buffer where data is stored. */ protected byte buf[]; /** * The number of valid bytes in the buffer. This value is always * in the range 0 through buf.length; elements * buf[0] through buf[count-1] contain valid * byte data. */ protected int count; protected boolean deleteTempFileOnClose = true; /** * Creates a new buffered output stream to write data to the * specified underlying output stream with a default 32-kbyte * buffer size. * * @author "Server Performance" http://serverperformance.blogspot.com */ public IntelligentBufferedOutputStream() throws IOException { this(DEFAULT_BUFFER_SIZE, true); } /** * Creates a new buffered output stream to write data to the * specified underlying output stream with a default buffer size. * * @author "Server Performance" http://serverperformance.blogspot.com */ public IntelligentBufferedOutputStream(boolean deleteTempFileOnClose) throws IOException { this(DEFAULT_BUFFER_SIZE, deleteTempFileOnClose); } /** * Creates a new buffered output stream to write data to the * specified underlying output stream with the specified buffer * size. * * @param size the buffer size. * @exception IllegalArgumentException if size <= 0. * @author "Server Performance" http://serverperformance.blogspot.com */ public IntelligentBufferedOutputStream(int size, boolean deleteTempFileOnClose) throws IOException { this.buf = new byte[size]; this.deleteTempFileOnClose = deleteTempFileOnClose; } /** Obtiene un InputStream, bien un BufferedInputStream del fichero temporal, bien * un ByteArrayInputStream del buffer en memoria (según el caso). * * @author "Server Performance" http://serverperformance.blogspot.com */ public InputStream getInputStream() throws IOException { if (in==null) { if (usedTempFile) { flushBufferToFile(); in = new BufferedInputStream(new FileInputStream(tempFile),buf.length); } else { in = new ByteArrayInputStream(buf,0,count); } } return in; } /** Copia el contenido del buffer (en memoria o en disco) a otro OutputStream. * * @author "Server Performance" http://serverperformance.blogspot.com */ public void writeTo(OutputStream target) throws IOException { // El tamaño del buffer temporal... pues el mismo que el original byte[] tempBuf = new byte[buf.length]; getInputStream(); int readedLen; while ((readedLen = in.read(tempBuf)) > 0) { target.write(tempBuf, 0, readedLen); } } /** Flush the internal buffer * * @author "Server Performance" http://serverperformance.blogspot.com */ private void flushBufferToFile() throws IOException { // Si no estaba creado, crea el fichero temporal if (!usedTempFile) { tempFile = File.createTempFile(TEMP_FILE_PREFIX,TEMP_FILE_SUFFIX,null); try { tempFile.deleteOnExit(); } catch (Throwable ignored) {} out = new FileOutputStream(tempFile); usedTempFile = true; } if (count > 0) { // Flush to disk! out.write(buf, 0, count); out.flush();; count = 0; } } /** * Consumes from de specified InputStream and writes into this buffered output stream. * ¡OJO! no cierra el inputstream, debe cerrarlo el invocante... * * @param in the origin/producer of the data. * @exception IOException if an I/O error occurs. * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public /*synchronized*/ void write(InputStream in) throws IOException { byte[] bufLectura = new byte[buf.length]; int len; while ((len = in.read(bufLectura)) > 0) { write(bufLectura, 0, len); } } /** * Writes the specified byte to this buffered output stream. * * @param b the byte to be written. * @exception IOException if an I/O error occurs. * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public /*synchronized*/ void write(int b) throws IOException { if (count >= buf.length) { flushBufferToFile(); } buf[count++] = (byte)b; } /** * Writes len bytes from the specified byte array * starting at offset off to this buffered output stream. * * Ordinarily this method stores bytes from the given array into this * stream's buffer, flushing the buffer to the underlying output stream as * needed. If the requested length is at least as large as this stream's * buffer, however, then this method will flush the buffer and write the * bytes directly to the underlying output stream. Thus redundant * BufferedTempFileOutputStreams will not copy data unnecessarily. * * @param b the data. * @param off the start offset in the data. * @param len the number of bytes to write. * @exception IOException if an I/O error occurs. * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public /*synchronized*/ void write(byte b[], int off, int len) throws IOException { if (len >= buf.length) { /* If the request length exceeds the size of the output buffer, flush the output buffer and then write the data directly. In this way buffered streams will cascade harmlessly. */ flushBufferToFile(); out.write(b, off, len); return; } if (len > buf.length - count) { flushBufferToFile(); } System.arraycopy(b, off, buf, count, len); count += len; } /** * Flushes this buffered output stream. This forces any buffered * output bytes to be written out to the underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.OutputStream#out * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public /*synchronized*/ void flush() throws IOException { if (usedTempFile) { flushBufferToFile(); out.flush(); } } /** * Writes b.length bytes to this output stream. * * The write method of OutputStream * calls its write method of three arguments with the * arguments b, 0, and * b.length. * * Note that this method does not call the one-argument * write method of its underlying stream with the single * argument b. * * @param b the data to be written. * @exception IOException if an I/O error occurs. * @see java.io.OutputStream#write(byte[], int, int) * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public void write(byte b[]) throws IOException { write(b, 0, b.length); } /** * Closes this output stream and releases any system resources * associated with the stream, including the memory buffer. * Also, delete the temporal file if so marked. * * @exception IOException if an I/O error occurs. * @see java.io.OutputStream#flush() * @see java.io.OutputStream#out * * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public void close() throws IOException { // Libera recursos del fichero temporal if (usedTempFile) { flushBufferToFile(); try { //if (out!=null) no puede ser nulo después de flushBufferToFile() out.close(); out = null; } catch (Throwable ignored) {} try { if (in!=null) in.close(); in = null; } catch (Throwable ignored) {} if (deleteTempFileOnClose) { try { // Borra el fichero temporal. // Aunque está marcado para ser borrado al cerrar la JVM, // por seguridad y optimización de recursos, lo hago ya tempFile.delete(); } catch (Throwable ignored) {} } if (deleteTempFileOnClose) { try { // Borra el fichero temporal. // Aunque está marcado para ser borrado al cerrar la JVM, // por seguridad y optimización de recursos, lo hago ya tempFile.delete(); } catch (Throwable ignored) {} } } // Libera recursos en memoria buf = null; } /** Returns the total buffer size * @author "Server Performance" http://serverperformance.blogspot.com * @author (Basado en) http://java.sun.com */ public int size() throws IOException { if (usedTempFile) { flushBufferToFile(); return (int)tempFile.length(); } else { return count; } } /** * @author "Server Performance" http://serverperformance.blogspot.com */ public void closeAndDelete() throws IOException { boolean oldFlag = deleteTempFileOnClose; deleteTempFileOnClose = true; close(); } /** * @author "Server Performance" http://serverperformance.blogspot.com */ public void finalize() { // Por si acaso... (en las clases de java.io también lo hace...) try { flush(); close(); } catch (Throwable ignored) {} } }

En cualquier caso, como muchas otras encapsulaciones, es algo que (al menos a mi) me parece una gran idea pero que en una Organización suele terminar no utilizándose por desconocimiento o por complejidad, o porque es un conocimiento que se pierde, o porque estaba mal documentado, o porque los procedimientos internos de comunicación eran más bien pobres hace unos años.

Es decir, es un código ideal para "núcleos" y componentes muy concretos, y quizás poco más.

En mi anterior vida, desde 2003 hasta hace unos meses, creo que este código se usado sólo en tres situaciones y me he quitado la espinita de encima porque en mi actual vida un invento de encapsulamiento muy similar a este nos ha salvado la vida en un caso muy concreto de invocaciones a módulos desacoplados donde podían darse situaciones de lo más diversa.

:-)

Java SE 6u6p Performance Release

2008-07-10T15:04:00.006+02:00

[Notas de octubre'08 y noviembre'08 ==>

Querido googler: si llegas a esta página -como muchos- buscando información de las performance releases del JRE 6, quizás te interesen los artículos posteriores Java SE 6u6-p Performance Release - YA DISPONIBLE EN OTRAS PLATAFORMAS, 6u6-p: Pues en Linux x64 peta!!!!!!! y Identificación de bugs en la versión 6u6p y workaround ]

Nueva actualización de rendimiento en Java 6. Continuando con lo comentado en la entrada Java SE 6u5p Performance Release, en julio Sun ha liberado ya la siguiente vuelta de tuerca: "JDK 6 Update 6 Performance Release" para plataformas SPARC. Del blog de David Dagastine:

I'm please to announce the release of JDK 6 Update 6 Performance Release on SPARC platforms. This is the latest of our performance releases and is the culmination of our optimization efforts over the last year. With this JDK Sun achieved many world records on SPECjappserver2004, SPECweb2005, SPECjbb2005, and the first ever SPECjvm2008 submission.

En breve estará disponible también para x64, aunque todavía no. Entre otras novedades, han mejorado el rendimiento en la clase TreeMap gracias a la aportación del equipo de Apache Harmony.

Referencias:

Daytona Terabyte: Yahoo! gana la competición de rendimiento 2008 utilizando Apache Hadoop

2008-07-07T03:37:00.005+02:00

No comment, aunque debería añadirlo también al post sobre mitos caídos...:

P.D: Como esto del "Java vs C++" es como lo del Madrid y el Barça (como tantas otras cosas, ver el artículo Sun Hotspot -vs- Bea JRockit), es decir que no puedes cambiar de opinión, se lo pasé a uno que me sé yo y su respuesta ha sido darles mérito a los ingenieros y programadores ("Tiene merito la cosa, han optimizado los algoritmos incluso para ganar desarrollándolo en java..."). Interesante reflexión :-)

"Double checked locking" por fin funciona en Java

2008-07-03T23:39:00.006+02:00

[Actualización noviembre 2008: referencia al final del post a un nuevo artículo de Jeremy "mascando" las variables volátiles en Java]

Es de todos conocido (espero) el pernicioso o impredecible efecto en Java del uso de la optimización "double-checked locking" tan usada en otros lenguajes como C++. El problema básicamente se da por dos motivos: en entornos multi-core / multi-procesador la JVM puede decidir que los threads utilicen copias locales de los punteros e incluso de algunas variables pequeñas para mejorar el rendimiento de acceso (las copias locales de la variable que tiene cada thread pueden no darse por enteradas del cambio global en condiciones de stress), aparte de que el compilador puede cambiar el orden de ejecución de algunas sentencias... :-(

Pero, desde J2SE 1.5, existe solución al problema añadiendo la palabra clave "volatile" como modificador de la variable que se utiliza como monitor, lo que asegura que todos los threads vean la misma versión de dicha variable, sin usar copias locales. Se penaliza muy levemente el rendimiento de acceso a esas variables dependiendo de la implementación de la JVM (pero mucha menos penalización que una región de exclusión mutua). Ahí está, el double-checked locking por fin funcionando en Java:

// Works with acquire/release semantics for volatile // Broken under Java 1.4 and earlier semantics for volatile class Foo { private volatile Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized(this) { if (helper == null) helper = new Helper(); } } return helper; } // other functions and members... }

En estos tres artículos está perfectamente explicado así que no añadiré mucho más:

P.D: En este artículo se explica perfectamente el modificador volatile y su comparación con synchronized: http://www.javaperformancetuning.com/news/qotm030.shtml

(...) volatile only synchronizes the value of one variable between thread memory and "main" memory, whilesynchronized synchronizes the value of all variables between thread memory and "main" memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.

Y hago referencia a un nuevo artículo divulgativo de Jeremy Manson explicando muy mascadito qué implica el keyword volatile en Java: http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html

Tamaño máximo de heap (y tamaño mínimo del heap)

2008-06-29T23:45:00.001+02:00

En otro artículo desgranaré algunos posibles argumentos / parámetros de lanzamiento de la máquina virtual. Pero una nota muy rápida para que quede claro, porque es una pregunta muy usada: ¿cuál es el tamaño máximo de heap adecuado para establecer con -Xmx?

Muy sencillo: la regla general es que en un servidor donde se está ejecutando una máquina virtual JAMÁS debe agotarse la memoria física. Jamás debe llegar a utilizarse el swap a disco. Nunca. Never. Jamais. Nie. Mai. Nooit.

Esto significa que sumando los heaps máximos de todas las máquinas virtuales que pueden ejecutarse en un servidor, deberemos asignar como máximo entre 0,5 y 1,5 GBytes menos de tamaños máximos de heap (sumados) que la memoria física de que dispone nuestra máquina. Nota: esta regla es fruto de mi experiencia, quizás por ahí haya otras medidas... ummm... ¿qué tal un 80%-20% o un 90%-10%? :-)

Es decir, si tenemos 16 gigas, usar siempre como máximo 14,5-15,5, el resto debe ser sufiente para tareas de automantenimiento, backups, scripts de consulta o consolas o sorpresas.

¿Por qué? Muy sencillo: el recolector de basura debe recorrer todo el heap, eso implica que si parte de éste está swapeado, el proceso de recolección generará un montón de fallos de página, lo que puede derivar en un auténtico desastre por OutOfMemoryError's muy frecuentes a poca carga que tengamos. Es decir, el modelo de GC no se lleva nada bien con un sistema de swapping a disco.

Y por cierto, para evitar fragmentación del heap y redimensionamientos no deseados en entornos de producción el tamaño inicial (-Xms) debe igualarse al máximo (-Xmx). Las pruebas demuestran que esto último tiene más importancia en la máquina virtual de Bea que en la de Sun.

También hay otras consideraciones a tener en cuenta, como el establecimiento de -Xmn para el tamaño de la zona de young generation (zona "Eden" + survivors), así como las políticas de promoción entre zonas y recolección de basura. Pero eso será objeto de ese artículo y no suele ser necesario si ayudamos a la JVM con -server/-client.

P.D: Aunque no es mi caso actualmente, además, tengamos en cuenta que cuanto mayor sea el heap, más le costará al GC hacer su trabajo, por lo que debemos tener cuidado con heaps de más de 50 gigas por mucho maquinón que nos pongan. Tenía por ahí alúna otra referencia que ahora no encuentro, dejo un link a http://dev2dev.bea.com/blog/hstahl/archive/2007/03/the_biggest_jvm.html ¿3,5 TBytes de heap? Guau!!!!.

Lo cierto, como aparece en un comentario que leí por ahí, es que si necesitamos semejante heap es que tenemos un problema de diseño de cojones en nuestra aplicación...

Out-of-Box Performance ("Out of the box")

2008-06-23T23:43:00.003+02:00

Se trata, para mi, de uno de los asuntos más importantes en el mundo de las máquinas virtuales: que el rendimiento y escalabilidad de una plataforma Java "sin tunear" (o auto-tuneada) sea muy parecida a lo que podríamos conseguir tuneándolo específicamente para un tipo de sistema o para un benchmark concreto.

Y digo que es importantísimo por tres motivos:

No siempre tenemos el tiempo adecuado para tunear todos los sistemas en cualquier circunstancia, o no siempre tenemos el equipo de ingeniero de sistemas adecuado, o no siempre tienen el tiempo o disponibilidad necesaria para hacer esas labores de tuning fino.
Las posibilidades de parametrización en el arranque de la máquina virtual son casi infinitas, un infierno me atrevería a decir, y las probabilidades de empeorar alguno de los aspectos de una aplicación cuando mejoramos perceptiblemente otros son muy altas, en mi experiencia, y no siempre son inmediatas de cazar.
El mundo no es inmóvil ni inmutable, y las condiciones en que se ejecuta un sistema van evolucionando (en concurrencia, carga, usuarios, tamaños de ficheros intercambiados, sistemas con los que se integra, nuevos elementos de red, etc), por lo que con el tiempo pueden dejar de tener sentido decisiones iniciales. Este problema es serio: me he encontrado con situaciones en las que había opciones de lanzamiento "heredadas" o no cambiadas en 3 años y al cambiar de versión de JVM ha sido contraproducente y una penalización en escalabilidad respecto a no haber puesto casi nada.

En este aspecto, las implementaciones modernas tanto de Hotspot como de JRockit tienen mejoras sustanciales. Fue muy sonado el anuncio de Sun en cuanto al Out-of-box performance del Java SE 6, aunque Bea asegura que su equivalente tiene incluso mejores prestaciones "Out-of-box".

¿Qué significa esto? Que con especificar parámetros en cuanto a tamaños de heap y poco más (ayudando con "-server"/"-client" pero en JRockit ni eso, al igual que Hotspot en algunos S.O.), hoy en día es casi suficiente para el 80% de las necesidades de nuestras aplicaciones y servicios. En algunos benchmarks que yo he hecho en mis aplicaciones, contrastándolo con una configuración "supertuneada" específicamente, la diferencia es sólo de entre un 0% y un 10% tanto en rendimiento como en escalabilidad. Mola.

Y lo que digo para Java SE se aplica en casi todos los órdenes de esta vida tecnológica: sistemas operativos, BIOS, etc.

Unas pocas referencias:

Buffers: por defecto y por exceso

2008-06-20T16:12:00.009+02:00

Llevo 11 años en el mundo Java. A lo largo de ese tiempo ven viniendo como los maderos a la playa los mismos error repetidos en quizás 20 ocasiones por personas distintas, en momentos distintos.

Defecto

Por ejemplo este: cargar todo el contenido de un fichero o un blob en memoria, no para trabajar con sus datos (que sería hasta discutible) sino para derivarlo hacia otra colaboración/proceso/cliente.

Hace poco me he encontrado, de nuevo, con un código similar a este para enviarle un fichero al navegador (eliminadas las partes de content-disposition, content-type, excepciones, etc):

input = new java.io.FileInputStream(pdf); int longitud = input.available(); byte [] datos = new byte [longitud]; input.read(datos); response.getOutputStream().write(datos); response.getOutputStream().flush();

Lo que podríamos catalogar de como mínimo "bestia" si no sabemos si puede tratarse de ficheros pequeños o grandes, o si vamos a tener un poquito de concurrencia. ¡Aparte de que vaya usted a saber qué valor devuelve el método available()!

Es cierto que cada vez la memoria es más "barata" y que tiende a pensarse que es infinita... pero también es cierto que el número de sesiones simultáneas, clientes concurrentes y tamaño de los ficheros / contenidos multimedia crece en una proporción similar. ¿Tanto cuesta utilizar un pequeño buffer?. Un código equivalente similar a este:

input = new java.io.FileInputStream(pdf); byte [] buffer = new byte [16*1024]; // 16 KBytes OutputStream output = response.getOutputStream(); int readed; while ( (readed = input.read(buffer)) > 0 ) { output.write(buffer, 0, readed); } out.flush();

Importantísimo: Sólo hay que escribir el tamaño real que el método de lectura ha metido en el buffer, lo que significaría que en la última escritura a la salida meteríamos basura detrás del final de lo que realmente teníamos que escribir, y eso puede dar problemas serios. Es decir me suelo encontrar con esta otra versión del bucle que es ABSOLUTAMENTE INCORRECTA (yo mismo la he cagao en alguna ocasión reciente, al loro):

while ( (fiPdf.read(buffer)) > 0 ) { out.write(buffer); }

Por cierto, en mi experiencia, en función de la arquitectura y sistema operativo, tamaños de entre 16 y 32 KBytes suelen ser los apropiados para este tipo de operaciones y para el uso de java.io.BufferedInputStream y java.io.BufferedOutputStream (por cierto esas clases usan por defecto un buffer 8KBytes si no especificas otra cosa en sus contructores).

Exceso

Por otro lado, también es común encontrarnos con el caso contrario: utilizar buffers cuando no hacen falta. ¿Cuántas veces hemos visto algo parecido a new GZIPOutputStream(new BufferedInputStream(new FileOutputStream(tempFile)))? ¿o ps.setBlob(1, new BufferedInputStream(new FileInputStream(tempFile),32*1024), tempFile.length()). Y el desarrollador, tan orgulloso de ser más listo que nadie.

Por regla general, si vamos a invocar a un método cuyo parámetro es un InputStream o un OutputStream, no hay que utilizar como intermediario un buffer porque por regla general el método invocado está optimizado. Es decir, debemos confiar en nuestros partners. Y por supuesto, si partimos de un array, no usemos un buffer como intermediario, ¡porque nuestro origen ya es un buffer!

En definitiva, tanto por exceso como por defecto, nos podemos encontrar con un sobre uso de la memoria con un efecto multiplicador más que curioso.

Muchas veces le doy vueltas a que deberían darle alguna que otra pensada a la implementación interna de los arrays en la máquina virtual; es decir que internamente la JVM hiciera swapping a disco de arrays grandes como uno de los pasos del recolector de basura, GC!!!

Hablando del tema... en su día yo hice una clase que era una especie de abstracción de todo esto: un "ByteArrayAdapter" que internamente decidía utilizar un byte array o un fichero temporal en función de tamaños y algunos que otros condicionantes, de forma transparente al desarrollador. El problema es el de siempre: difícil de explicar y difícil de recordar que existe si no eres el creador de la criatura, y una cosa más que mantener. Repito el autoconsejo de uno de los primeros posts: cuanto menos contenido tenga la biblioteca propia de clases de nuestra compañía / grupo de trabajo / producto, mucho mejor. (¿Por qué todos nos empeñamos en que tenemos que tener una biblioteca estándar en nuestra empresa? ¿por qué tenemos que creernos más listos que las comunidades opensource? ¿por qué terminamos teniendo cuatro versiones de lo mismo que encima los nuevos integrantes de los equipos terminan "olvidando"? Si siempre pasa lo mismo, no caigamos en lo mismo de siempre.

Bueno, que me he ido del asunto. Volvemos a lo de siempre: seguimos necesitando que el desarrollador sea un ser pensante y con experiencia. Afortunadamente, por cierto.

Nota: el tema de este post en realidad es la escalabilidad más que el rendimiento :-)

Java CAPS y Open ESB: Enlaces de interés y recursos

2008-06-17T14:34:00.005+02:00

Una recopilación no exhaustiva de referencias sobre Java CAPS y en menor medida sobre Open ESB, y no sólo de temas relacionados con rendimiento o escalabilidad. Iré actualizándola...

[Actualizado el 25/8/2008: añadidos algunos enlaces de interés tomados del blog CamelCase, como la nueva wiki]

Soporte y Documentación oficial de Sun:

Foros:

Wikis:

Herramientas y otros:

Libros:

http://www.amazon.com/Java-CAPS-Basics-Implementing-Patterns/dp/0137130716

Videos:

Blogs:

del.icio.us

Technorati

Twitter

Facebook

http://www.facebook.com/group.php?gid=17757823536

Nota: Muchas de estas referencias son recopilación mías, pero otras muchas están copiadas de la gran recopilación hecha por Sebastian Krueger (http://jcapsblogger.blogspot.com/2008/04/some-tips-on-following-java-caps-news.html) y he tomado otras del blog CamelCase referenciado arriba).

Sun Hotspot -vs- Bea JRockit

2008-06-14T16:10:00.009+02:00

Actualización 19/9/2008: Nuevo blog corporativo de Henrik, ahora que les ha comprado Oracle...

Dejo enlaces a los weblogs de miembros de los equipos de rendimiento de Sun y de Bea (ahora Oracle), para sus respectivas máquinas virtuales, Hotspot y JRockit. Algunos artículos son más que interesantes:

Je, je, es la gran batalla que da "vidilla" al rendimiento y escalabilidad en Java sobre plantaformas x86 y x64. Una vez más se demuestra que la competencia fomenta la innovación y el avance (vaya, esto parece un alegato capitalista antimonopolio :-) Bueno, están IBM y HP por ahí también, sobre todo IBM tuvo ganada la partida en el mundo Intel en los tiempos del JDK 1.1 y 1.2... pero para mi hoy en día son convidados de piedra en este juego, especializados en sus arquitecturas respectivas.

¿Y tú de quién eres? No, no, no se puede ser agnóstico, hay que tomar partido. Esto es como las decisiones Rolling/Beatles, Intel/AMD, Barça/Madrid, Windows/Linux, Cocacola/Pepsi, Fanta/Kas, MortadeloFilemón/ZipiZape, Astérix/Tintín, Demócratas/Republicanos, Google/Yahoo, Java/C++, Redhat/SuSE. Hay que tomar partido. Y defender tu posición. :-)

Si tengo que ser sincero, le tengo especial cariño a JRockit por aquello de que me sacó de un gran apuro hace ya tiempo en un proyecto, sólo con cambiar de máquina virtual y tunear algunas cosillas... aquello fue como magia. Pero eran los tiempos en que acababa de salir el JDK 1.4.2 y ha llovido mucho desde entonces.

Y como cada uno cacarea los resultados que quiere en sus publicidades, y mi sensación es que a día de hoy ambas tecnologías son muy parejas, mi opinión es que hoy en día hay que ser pragmático: si vas a ejecutar un Weblogic / Aqualogic, móntalo sobre JRockit; y si vas a ejecutar un Glassfish / JES / Java CAPS, hazlo sobre la JVM de Sun.

Porque suelen venir ya "pretuneados", o al menos han sido muy probadas esas combinaciones, y porque no quiero tener problemas cuando reporto una incidencia a los equipos de soporte de Sun y de Bea respectivamente. Porque su primera respuesta es obvia ante un reporte de incidencia, esto es como cuando vas al médico por lo que sea: ya sabes que lo primero de todo te va a decir que dejes de fumar y que adelgaces. Aunque tengas una rotura de fibras.

Es decir, reconozco que hoy en día estoy utilizando Sun Java SE 6.0 sobre Linux x64. Pero algún día jugaremos un poco a ver qué pasa...

P.D: Por cierto, he mantenido una conversación por email muy interesante con Henrik Ståhl. Y he de reconocer que estoy gratamente sorprendido no sólo por su capacidad profesional (que se le presupone) sino por su amabilidad e interés acerca de mis necesidades / caso de uso.

Disclaimers (II)

2008-06-14T16:08:00.003+02:00

Otra cosilla, aparte de otros disclaimers generales (por cierto, literalmente Disclaimer significa "Negación").

Lo que aquí voy dejando para la posteridad no tiene por qué ser la Verdad absoluta, incluso puede que esté muy equivocado en más de una aserción. Son mis opiniones y/o experiencias en unos entornos, aplicaciones y momentos concretos que pueden diferir de lo que algún googler eventualmente vaya buscando si termina parando en esta esquinita de la web.

Es curioso porque el ser humano tiende a poner en tela de juicio constantemente versiones oficiales, leyes, libros, dogmas de fe, teorías científicas, lo que nos dicen los consultores de las grades empresas, etc, pero por el motivo que sea tendemos a creer que lo que encontramos googleando o en la wikipedia es la verdad absoluta. Que el anonimato obliga. Por algo se habrá escrito. El autor no gana nada con mentir deliveradamente.

Pero la realidad no tiene por qué ser esa, y no por mala fe. En el 70% de los casos la gente escribe de oídas o porque lo ha leído en otro foro o blog, y en raras ocasiones alguien se ha molestado en hacer una prueba de carga en condiciones y de perfilar una ejecución. En cualquier caso siempre estamos influidos por los prejuicios, o por lo que nos infundió gente a la que respetamos, o de empresas/apuestas a las que tenemos má cariño que a otras.

Así que aviso para navegantes, estas son mis opiniones, esta es mi verdad, que puede cambiar con el tiempo :-)

Java SE 6u5p Performance Release

2008-06-11T23:58:00.015+02:00

[Nota de octubre'08 ==>

Querido googler: si llegas a esta página -como muchos- buscando información de las performance releases del JRE 6, quizás te interesen los artículos posteriores Java SE 6u6p Performance Release,
Java SE 6u6-p Performance Release - YA DISPONIBLE EN OTRAS PLATAFORMAS y 6u6-p: Pues en Linux x64 peta!!!!!!!]

Aunque la noticia tiene más de un mes, yo lo acabo de descubrir: Sun lanza una versión especial de Java SE 6 (llamada 6u5p) incluyendo las últimas innovaciones en rendimiento que eventualmente se incorporarán a futuras versiones de la plataforma.

Copia literal de la web de Sun:

May 2008
Java SE 6u5p Performance Release
This special version of Java SE includes the very latest performance innovations from Sun on selected platforms. The software is free for download, application performance testing, and benchmark submissions. Performance releases may be used in production. If desired, support is available via a Sun Java support contract. These performance enhancements will be included in an upcoming standard release of the Java SE platform. Please share with us your experience using this special advance release.

Y veo este mini resumen en estas trasparencias de Java One - http://blogs.sun.com/dannycoward/resource/PS_TS-6271_SETrackTalk_Final.pdf:

Java SE 6u5p “Performance Release”
Performance tuned release of the JRE™64bit architectures only
Solaris, Windows, Linux
Large number of small optimizations
Crypto libraries, TreeMap, HashMap, XML Parsing
Escape analysis, depth-first copying, page sizes
Optimizations seep into future JRE updates

Un poco exagerada la promesa de mejora que se ve en el gráfico de abajo ¿no?

Sun no está dando mucha información de qué incorpora (o yo no lo he encontrado), pero la gráfica de arriba es prometedora, y parte de la información de mejoras también... ¿eso de optimizar TreeMap, HashMap y XML Parsing no recuerda sospechosamente a algunas de las técnicas utilizadas en la biblioteca de Javolution? (ver http://serverperformance.blogspot.com/2008/06/javolution.html).

Pero siempre que ocurre alguna promesa de "milagro" de estos en lo que a rendimiento se refiere me surgen siempre dos dudas: ¿cuánto hay de cierto? y, lo que me come por dentro... ¿es que ahora somos muy listos o es que hasta hace 6 meses éramos todos muy tontos?

Puede solicitarse su descarga desde http://java.sun.com/performance, donde por cierto hay también unos cuantos documentos y recursos sobre rendimiento, escalabilidad y tunning.

Buena noticia esta "iniciativa 2.0". Creo que es la primera versión de anticipos de rendimiento que liberan así, como se ve en alguna gráfica de temporalidad de versiones, pero seguro que no es la última... habrá que ir chequeándolo...

En general me gusta la política de semi-puertas abiertas que tanto Sun con Bea/Oracle están siguiendo...

P.D: Ojo con utilizar esta versión en producción sin probarla muy-muy bien, veo en algunos foros y bug parade que ciertas opciones de GC fallan o que en algún caso muy concreto se comporta distinto que su hermana la versión estándar... Como siempre, es mejor seguir la máxima "que prueben otros" salvo necesidades muy bien justificadas o actualizaciones menores de software (esta no lo es aunque lo parezca), aunque la cabra tira al monte y el cuerpo nos pide marcha...

Rendimiento en transformaciones XSLT

2008-06-09T22:34:00.023+02:00

Esta vez voy a referenciar una serie de tres grandiosos posts hechos en el blog "Algo nuevo que hacer..." (http://www.cmaj.es/). Se trata de un blog muy interesante salpimentado con una pizca de tecnología y dos pizcas de liderazgo de equipos de trabajo y motivación.

XSLT en Java: uso de Translets

Si estás -como yo- preocupado por el rendimiento y escalabilidad de las transformaciones XSLT en Java, ya habrás llegado a la conclusión de que la única forma de que el rendimiento y escalabilidad del cruce de un XML con su plantilla XSL sea decente es el uso de "translets", esto es clases precompiladas:

No obstante, sigue este gran artículo dividido en tres entregas, muy interesante por la evolución cronológica que marca y por las sorpresas y tunnings realizados:

"Transformaciones XSL (I): Rápidas como el rayo". http://www.cmaj.es/2007/10/02/14/
"Transformaciones XSL (II): ¿Cuanto más rápidas son ahora?". http://www.cmaj.es/2007/10/10/transformaciones-xsl-rapidas-como-el-rayo-ii/
"Transformaciones XSL (III): No es oro todo lo que reluce". http://www.cmaj.es/2008/01/23/transformaciones-xsl-iii-no-es-oro-todo-lo-que-reluce/

El "gato encerrado" descubierto en el tercer post hace que cada vez que reafirme más en esa sentencia que es recurrente en mis posts y conversaciones: si un framework deja dos opciones para hacer lo mismo, en el 50% de los casos se utilizará la incorrecta. Y lo que es peor, Murphy dice que el 100% de esas veces siempre pasa en proyectos más críticos y en sus peores fases. Venga pongámosle nombre a esta ley... ¿qué tal la Ley del Chikilicuatre?

¿Por qué entonces, joder, nos empeñamos todos los arquitectos software en dejar para la posteriidad múltiples opciones de implementación o parametrización cuando rara vez tiene sentido algo distinto de la opción "lógica"? ¿para que los desarrolladores tengan más emoción en sus vidas????

P.D: [OFFTOPIC - Reflexión personal sobre el uso de XSLT]:

La tecnología XSLT es muy interesante desde el punto de vista teórico para independizar la capa de presentación de la tecnología concreta en que se desarrolla el resto de la aplicación. Es decir, en un mundo ideal podemos tener un equipo especializado 100% en XSLT + HTML + Javascript + AJAX, y que ese equipo intervenga tanto en proyectos Java, .NET, Python, RoR, PHP, o lo que sea. Yo mismo he apostado por esa estrategia en el pasado.

Pero esa es la teoría, la realidad dice que muy pocas Compañías pueden permitirse ese grado de equipos/perfiles especializados, más bien generalmente el 95% de tus proyectos son mono-tecnología (Java en mi caso) y en la Organización no existen los perfiles especializados sino genéricos o todoterreno. En ese caso una constante suele ser que el 100% de tus desarrolladores se sienten "javeros" (o lo que toque) y sorprendentemente les da "alergia" cualquier cosa distinta (y en ese saco meto tanto SQL como XSLT, HTML o Javascript)... y ahí tenemos un problema de cojones!.

Conclusión: es mejor dejarse llevar por las fuertes corrientes e implementar la capa de presentación con Struts, JSF o lo que toque. Porque es lo que conocen los técnicos tanto de dentro como de fuera, y cuanto más distinto o especialito seas, más te cuesta sustituir a una persona o ampliar un equipo.

Corolario: el uso de XSLT puede llegar a ser equivalente o superior en cuanto a rendimiento en tiempo de ejecución, pero siempre va a ser muy inferior en cuanto a rendimiento del equipo de trabajo. Al menos en un par de años vista...

Mitos sobre rendimiento y escalabilidad

2008-06-06T20:33:00.007+02:00

Una recopilación de buenos enlaces, ellos sí que saben. Y en la PPT va probablemente una de las mejores frases que he leído en meses: "clever code confuses clever JVMs". o lo que es lo mismo "no te pases de listo" :-)

Tengo que reconocer que alguno de los puntos de la PPT me ha sorprendido, como que actualmente la sincronización en sí misma no es excesivamente costosa, sino que lo que sigue siendo costoso es la contención de threads. En otras palabras: en teoría "casi" es lo mismo usar un StringBuilder en lugar de StringBuffer cuando sólo un thread simultáneamente pasa por las regiones de exclusión mutua (lo que choca con lo que dije precisamente en uno de los primeros posts). ¿Es una gran equivocación o es que me estoy volviendo viejo y sigo tomando como ciertas cosas que eran verdad en la época del JDK 1.1, 1.2 y hasta 1.3 pero ya no lo son??? Si fuera verdad... ¿para qué crear la nueva StringBuilder? Ummm... Habrá que hacer pruebas de rendimiento (lo cierto es que en muchos aspectos casi todo el mundo habla de oídas)... [Actualización 1/9/2008: puede verse información detallada acerca de benhmarking comparativo aplicando distintas opciones de lanzamiento de la JVM sobre esta y otras opciones de optimizaciones sobre el modelo de Threading en el post ¿Funcionan las optimizaciones sobre el modelo de threading?]

Y por cierto, como me han recordado hoy, rendimiento no es sinónimo de escalabilidad. Hay que tener claros los conceptos y los objetivos en cada caso. En muchos casos los pasos para conseguir ambos objetivos son los mismos pero muchas otras veces son términos casi incompatibles. La cuestión es saber cuál es el término medio como siempre...

Mitos y leyendas (antiguos y actuales) sobre el rendimiento en Java. BUENÍSIMO: http://www.cs.umd.edu/users/jmanson/java/presentations/sdwest2008.ppt

¿Es de verdad la NIO no bloqueante mejor que la IO bloqueante "de toda la vida" para un servidor de aplicaciones? Los procesadores multicore cambian las reglas del juego:

http://jutopia.tirsen.com/2008/03/07/threads-dont-scale-they-might-do-now/

Blog sobre concurrencia y sincronización. Un tío listo: http://jeremymanson.blogspot.com/

Y hablando de mitos y leyendas...

JDBC 4.0 y Oracle 11G: combinación ganadora

2008-06-04T12:06:00.021+02:00

La versión 4.0 de JDBC, incorporado en Java SE 6.0, supone un salto importante en cuanto a rendimiento en muchos pequeños aspectos. Uno de ellos es la mejora en los pooles, y otro ejemplo -en el que me voy a centrar hoy- son los LOBs. Este artículo no pretende ser un estudio exhaustivo acerca de JDBC 4.0, para eso mejor visitar por ejemplo algunos de los enlaces de abajo (en concreto el de onjava.com o el de ibm-developerworks).

Estas mejoras pueden no ser significativas en algunos/muchos entornos, pero sí que lo son en servidores con mucho estrés o en temas muy concretos como el uso de LOBs, que por fin se pueden gestionar de una forma coherente y sencilla.

Por ejemplo, se han añadido a PreparedStatement los métodos:

/**
* Sets the designated parameter to a InputStream object. The inputstream must contain the number
* of characters specified by length otherwise a SQLException will be
* generated when the PreparedStatement is executed.
* This method differs from the setBinaryStream (int, InputStream, int)
* method because it informs the driver that the parameter value should be
* sent to the server as a BLOB. When the setBinaryStream method is used,
* the driver may have to do extra work to determine whether the parameter
* data should be sent to the server as a LONGVARBINARY or a BLOB
* @param parameterIndex index of the first parameter is 1,
* the second is 2, ...
* @param inputStream An object that contains the data to set the parameter
* value to.
* @param length the number of bytes in the parameter data.
* @throws SQLException if parameterIndex does not correspond to a parameter
* marker in the SQL statement; if a database access error occurs;
* this method is called on a closed PreparedStatement;
* if the length specified
* is less than zero or if the number of bytes in the inputstream does not match
* the specfied length.
* @throws SQLFeatureNotSupportedException if the JDBC driver does not support this method
*
* @since 1.6
*/
void setBlob(int parameterIndex, InputStream inputStream, long length) throws SQLException;

/**
* Sets the designated parameter to a Reader object. The reader must contain the number
* of characters specified by length otherwise a SQLException will be
* generated when the PreparedStatement is executed.
* This method differs from the setCharacterStream (int, Reader, int) method
* because it informs the driver that the parameter value should be sent to
* the server as a CLOB. When the setCharacterStream method is used, the
* driver may have to do extra work to determine whether the parameter
* data should be sent to the server as a LONGVARCHAR or a CLOB
* @param parameterIndex index of the first parameter is 1, the second is 2, ...
* @param reader An object that contains the data to set the parameter value to.
* @param length the number of characters in the parameter data.
* @throws SQLException if parameterIndex does not correspond to a parameter
* marker in the SQL statement; if a database access error occurs; this method is called on
* a closed PreparedStatement or if the length specified is less than zero.
*
* @throws SQLFeatureNotSupportedException if the JDBC driver does not support this method
* @since 1.6
*/
void setClob(int parameterIndex, Reader reader, long length) throws SQLException;

Esto implica que, con bases de datos Oracle, nunca más sea necesaria la creación de un blob temporal a través de la API propia de Oracle y posterior asignación a la nueva fila sin que de forma mucho más intuitiva y estándar podemos hacer lo siguiente para insertar datos en una columna de tipo BLOB:

File originalFile = new File(PATH); Connection conn = ...; PreparedStatement ps = conn.prepareStatement("..."); ps.setBlob(1, new FileInputStream(originalFile), originalFile.length()); ps.execute(); ps.close(); conn.close();

No sólo es más elegante, sino que en Oracle 11G supone un incremento de hasta un 25% en el rendimiento frente al tradicional método con "BLOB.createTemporary()" propietario de Oracle (son mis datos empíricos con ficheros de más de 10 megas). Lo cual sumado al uso de los nuevos SECUREFILEs para almacenar LOBS, significa que la combinación Java 6 + JDBC 4 + Oracle 11G suponga hasta casi un 50% más de rendimiento que Java SE 1.5 + JDBC 3 + Oracle 10G en la inserción de LOBs de gran tamaño.

Para más información acerca de los cambios que supone JDBC 4 sobre sus antecedores:

Javolution

2008-06-02T10:06:00.024+02:00

http://javolution.org/

¿Operaciones de inserción en strings de orden logarítmico en lugar de lineal?

¿Alguien que por fin se acuerda de optimizar específicamente los marshallings/unmarshailling de XML?

Eso mola...

Se trata de una biblioteca de clases básicas, muchas de ellas "sustitutivas" de las que vienen en la biblioteca estándar del JDK, cuyo principal objetivo es el alto rendimiento y la predictibilidad (determinismo) del mismo. Principalmente pensada inicialmente para sistemas de tiempo real y empotrados, aunque como puede verse también puede ser de gran utilidad en sistemas servido con mucha concurrencia o necesidades de rendimiento y escalabilidad.

La biblioteca estándar del JDK tiene un problema general: está pensada para no dar problemas en ningún entorno, por lo que puede no ser la mejor solución siempre. Por ejemplo, la mayor parte de las clases son threadsafe, lo cual significa que por ejemplo la concatenación en un StringBuffer o el uso de una tabla de hash está lleno de regiones de exclusión mutua y uso de monitores. Siendo que en el 95% de los casos son completamente innecesarias debido a que hoy en día un desarrollador trabaja dentro de un framework, o genera código para un EJB, etc, y ese objeto sólo va a ser ejecutado por un thread en cada momento.

Por supuesto, con el tiempo Java ha evolucionado en dos líneas:

Por un lado cada revisión de la máquina virtual / Hotspot VM hace que se reduzca la penalización por el uso de monitores allá donde no hacían falta.
Por otro lado, poco a poco en el JDK se han ido introduciendo versiones "no sincronizadas". Por la propia filosofía de compatibilidad hacia atrás, el tema va quedando al menos "raro", pero es lo que hay. Por ejemplo:

java.uti.HashMap (que ofrece la misma funcionalidad que la java.util.Hashtable de toda la vida).
java.lang.StringBuilder por fin desde el JDK 1.6 supone una alternativa "no sincronizada" al infame java.lang.StringBuffer. (¿De verdad nadie se había dado cuenta hasta ahora que en el 99,999999% de las veces la concatenación de cadenas se usa en un contexto threadsafe?????)

El problema de separar así la API es que estás delegando en la capacidad, memoria, experiencia y entrenamiento del desarrollador. Mi experiencia dicta que "si quieres que algo se haga de una cierta forma, no des dos opciones para ello; en un 50% de los casos se utilizará la incorrecta". No sé si hay una ley para ello, o si no le ponemos un nombre. Claro que para que tenga éxito la postulación tenemos que poner mejor las cantidades 80-20 por algún lado ;-)

En esta línea llega Javolution. Me gusta, y mucho. Probablemente porque es lo que yo siempre he querido hacer, probablemente porque me he enamorado de su código fuente.

Pero tiene una pega, probablemente insalvable: en el fondo lo mismo que comento arriba: se trata de algo nuevo que aprender, no estándar y que los desarrolladores que hay en el mercado y entran nuevos a tu equipo no están habituados a utilizar. Es decir, mal rollo salvo que se utilice en un contexto muy concreto dentro de un producto o exclusivamente en las partes críticas de un proyecto.

También tiene otra pega que he sufrido yo en intentos similares anteriores: las siguientes revisiones de la JVM o del JDK pueden hacer inservibles parte de las optimizaciones, o que se optimicen las clases estándar más allá de la línea que ha podido seguir Javolution.

Y finalmente: hay que saber lo que está haciendo. Hay que "ayudar" a las optimizaciones de forma declarativa indicando contextos de trabajo... Y no me gusta tener la obligación de que todo desarrollador de un equipo sea un auténtico experto en rendimiento o cuncurrencia.

Más que reconmendable, sobre todo en sistemas de tiempo real, pero teniendo siempre presente que no existen los milagros (sino que lo importante es la suma de muchos pequeños detalles) y también en cuenta las reflexiones de arriba ("gato escaldado del agua fría huye").

Como muestra un botón: benchmarking de parsers XML --http://www.xml.com/pub/a/2007/05/09/xml-parser-benchmarks-part-1.html?page=2

En cualquier caso, mi conclusión es:

Utilizarlo sólo en los proyectos y contextos en que sea inevitable, o crítico
Muy interesante para conocerlo y aprender de por qué y cómo está hecho
Muy interesante para que los señores que desarrollan el JDK (ahora es Open Source así que debería estar más abierto a ideas frescas), así como implementadores de las APIs más comunes y equipos de desarrollo de servidores de aplicaciones varios
Muchas veces de nada serviría utilizarlo en nuestro proyecto, si no lo aplica el servidor de aplicaciones que hay por debajo, y que también habría que meterle mano para que realmente se note un cambio en la tendencia de respuesta o rendimiento.

Por cierto, que en la documentación de la API puede verse unos gráficos comparativos de tiempos de resupuesta de cada clase frente a su "competidora" en el JDK...

Compresión HTTP

2008-05-30T20:30:00.022+02:00

[Actualizado Oct'08 para corregir la parte de XML de configuración de Glassfish, el editor de Blogger me había cortado algunas cosas... :-(]

Es increíble que a día de hoy, año 2008, todavía un gran porcentaje de sitios y servicios web no tengan implementada ni la optimización más básica de todas: compresión de los contenidos servidos para aligerar las comunicaciones.

¿Por qué Google es el buscador más rápido? ¿por qué eBankinter es la banca online más rápida? Por mil cosas, y una de ellas es esta, claro. Y otra es la correcta gestión de las cabeceras de expiración de contenidos, pero eso puede que sea objeto de otra entrada... :-)

El protocolo HTTP lo soporta desde "casi siempre" y los navegadores también, incluso aquellos Netscape 4 e internet Explorer 4 de los que ya no nos acordamos y que tantos quebraderos de cabeza nos dieron hace unos añitos... Y el protocolo FTP también lo soporta (el llamado "Z Mode").

No voy a entrar en las posibilidades o particularidades, o en qué situaciones es más perjudicial que beneficioso porque al fin y al cabo consumimos recursos de procesamiento tanto en cliente como en servidor (por lo general en aplicaciones de Intranet en las que el ancho de banda es realmente alto). Pero, por lo general un fichero HTML normalito tiene una tasa de compresión con GZIP de entre 5:1 y 15:1. O lo que es lo mismo, una página de 200 KByes puede suponer que en realidad al navegador transmitamos sólo 20 KBytes. Y eso no sólo es importante en términos de visitantes unitarios, sino en términos de ancho de banda servidor en situaciones de concurrencia importante.

El protocolo HTTP, por ejemplo, define un diálogo muy sencillo entre el cliente (navegador) y el servidor, para el primero informe al segundo de sus "capacidades" y el segundo informe al primero de si el contenido está comprimido o no. Se hace a través de las cabeceras HTTP. Por ejemplo:

Header en la petición:
Accept-Encoding: gzip, deflate
Headers en la respuesta:
Vary: Accept-Encoding Content-Encoding: gzip

¿Mola? Pues es trivial de implementar. Tanto el IIS como Apache Web Server (a través de mod_deflate o mod_gzip) como Glassfish, Tomcat, Orion, etc, etc, lo soportan.

Algunos ejemplos sencillos.

En Tomcat basta con añadir al tag <Connector> del fichero server.xml:

compression="on" compressableMimeType="text/html,text/xml,text/css,text/javascript,text/plain,application/x-javascript,text/unknown,text/*"

En Glassfish basta con añadir lo equivalente en el domain.xml, dentro de las secciones <http-listener> que deseemos:

<property name="compression" value="on"/> <property name="compressableMimeType" value="text/html,text/xml,text/css,text/javascript,text/plain,application/x-javascript,application/force-download,application/pdf,text/unknown,text/*"/>

En Apache es también trivial; por ejemplo en Apache 2.2 con mod_deflate la configuración sería:

AddOutputFilterByType DEFLATE text/html text/xml text/css text/javascript text/plain application/x-javascript application/force-download application/pdf text/unknown text/*

En iPlanet idem, además se permite tanto la carga de archivos "precomprimidos" y la compresión al vuelo. Para la compresión dinámica:

Output fn="insert-filter" filter="http-compression" type="text/*" vary="on" Output fn="insert-filter" filter="http-compression" type="application/x-javascript" vary="on" Output fn="insert-filter" filter="http-compression" type="application/force-download" vary="on" Output fn="insert-filter" filter="http-compression" type="application/pdf" vary="on"

Y para soporte a archivos precomprimidos en iPlanet (deben existir las dos versiones, por ejemplo "prueba.js" y "prueba.js.gz"). Aquí habrá que hacerlo por cada extensión o similar (no es un filtro de salida sino un procesamiento previo, por ejemplo para aplicarlos a ficheros .js:

<Object ppath="*/*.js"> PathCheck fn="find-compressed" check-age="on" vary="on" </Object>

Hay unas cuantas opciones que considerar (como el tamaño mínimo de un fichero para que lo comprima, o si debe ignorar algunos navegadores) e instrucciones a los proxy caches para indicarle que este contenido es una variante (es decir que envíe la cabecera Vary: Accept-Encoding), pero básicamente ahí está...

Además de compresión por software, se puede utilizar hardware de aceleración especializado para ello, pero eso también será objeto de otra entrada...

Algunos links de interés:

Disclaimers

2008-05-30T17:37:00.007+02:00

EN NINGUNO DE LOS CASOS LAS OPINIONES EXPRESADAS REFLEJAN LA POSICIÓN DE MI EMPRESA O DE NINGUNA DE LAS ORGANIZACIONES PARA LAS QUE COLABORE O HAYA COLABORADO. Los ejemplos o situaciones descritas son absolutamente inventadas y cualquier parecido con la realidad es mera coincidencia. (Siempre quise decir esa frase)

Este blog no tiene ningún fin lucrativo o comercial, sino meramente de bitácora y divulgativo. En las entradas del mismo pueden mencionarse -sin intención publicitaria ni vinculación alguna con sus propietarios- productos y/o marcas comerciales registradas por sus propietarios. Si en algún caso dicho propietario entiende que se están vulnerando sus derechos o prefiere que se elimine alguna referencia o comentario, ruego se pongan en contacto conmigo.

Del mismo modo, algunas de las imágenes incluidas pueden tener derechos de autor, de modo que de nuevo ruego a sus propietarios que se pongan en contacto conmigo si se desea retirar alguna de ellas.

Introducción

2008-05-30T15:56:00.015+02:00

Bienvenido a mi espacio de reflexiones.

Mi objetivo con este blog es publicar mis reflexiones anónimas sobre mis áreas de interés, conforme vaya surgiendo la oportunidad dentro de mis responsabilidades profesionales.

Llevo unos cuantos años relacionado profesionalmente de una forma u otra con tecnologías internet, y fui uno de los pioneros en España en el uso de Java en general (JDK 1.0 y 1.1 allá por 1997) y de los EJB 1.0 en particular (allá por finales de 1999). Eso son más de 11 años a día de hoy.

Actualmente lidero un equipo técnico dedicado al desarrollo de soluciones servidor en Java EE, abarcando distintas líneas de actuación. A lo largo del tiempo van surgiendo nuevos problemas (o se van reitiendo patrones antiguos) relacionados con el rendimiento de los servidores, de la base de datos, del propio desarrollo Java EE, de HTTP/S, de SOAP, de los nuevos paradigmas RIA/AJAX... de modo que mi objetivo es ir recogiendo a modo de bitácora esos elementos.

Por experiencias pasadas, no pienso comprometerme a escribir con regularidad ni a hacerlo en profundidad. He tomado mucho de otros gracias a la gran telaraña, si además de servir de memoria personal estas reflexiones pueden servirles a otros, bienvenido sea!!!

Me encantaría escribir las entradas también en inglés, pero mis limitaciones hacen que lo haga sólo en el idioma de Cervantes...

Saludos,
--Server performance