Batch4j - Batch for Java TM - Un deseo o pura necesidad
La mayoria utilizamos bien a traves de Sun o directamente el API AXIS, no obstante el rendimiento del mismo es bastante mejorable.
Encontramos proyectos como http://vijava.sourceforge.net/ que nos prometen mejoras impresionates.
4 veces en serializacion/deserializacion.
15 veces en carga de clases.
Creo que una libreria tan utilizada deberia cuidarse un poco mas, pero hemos visto casos similares con Hash ..
Internamente utiliza dom4j que es mas rapido que el api de DOM.
Si necesitais un poco mas de velocidad no dudeis en probarlo, igual merece la pena mejorar la arquitectura en vez de limar en la parte de negocio.
Posted at 11:51AM may 13, 2009 by Batch for the Java TM in General | Comentarios[5]
Creo que me he perdido.
VMware Infrastructure Java API (vijava) y AXIS (siempre y cuando se trate de Apache AXIS) son API diferentes para cosas diferentes.
Vale que Axis no está tan depurado como debería, pero a día de hoy la versión de Axis2 1.4 es bastante estable y al utilizar el modelo de objetos AXIOM (The Axis Object Model) que por debajo utiliza la API de Stax se obtiene un rendimiento más que digno, con un consumo de memoria aceptable, además de simplificar bastante (pero que bastante, el desarrollo tanto de servicios web como de clientes para los mismos)
He tenido la oportunidad de probarlo en distintos entornos de producción en varios proyectos y a día de hoy estoy más que satisfecho y más aún con la versión 2.
Un saludo.
Enviado por bellz en mayo 13, 2009 a las 03:11 PM GMT+01:00 #
Tengo un problema de rendimiento con axis en un entorno de produccion bastante critico. Buscando una alternativa a AXIS he encontrado que VMware Infrastructure Java API (vijava) utiliza su propio sistema para llamar a WebServices sin utilizar AXIS y que segun comentan tienen un rendimiento superior.
Como veras si no estuviera desesperado, por los malos tiempos de respuesta de AXIS no intentaria salirme del estandar de facto.
Enviado por batch4j en mayo 13, 2009 a las 03:18 PM GMT+01:00 #
Quiza Xfire o CFX te puedan servir.
Un saludo.
Enviado por bellz en mayo 13, 2009 a las 03:43 PM GMT+01:00 #
¿No estarás usando Axis1? Porque Axis2 es rapidísimo.
Puedes probar a cambiar el OXM. ¿Cúal usas? ¿ADB, XMLBeans?
Otra opción, si realmente te importa hasta el último milisegundo es no usar SOAP :-) O darle otra vuelta a los procesos e intentar usar servicios asíncronos.
Enviado por jcpa en mayo 13, 2009 a las 04:37 PM GMT+01:00 #
Ya encontre el problema, resulta que AXIS utiliza log4j y aunque tenemos modificado el nivel de logs, habia una aplicacion que utilizaba su propia configuracion y activaba todos los logs de AXIS, cuando en un servidor tienes cientos de EJB, WAR, EAR etc te puede pasar.
El pobre rendimiento del AXIS se debe a la activacion de los logs.
Enviado por batch4j en mayo 28, 2009 a las 11:41 AM GMT+01:00 #