Herramientas de rendimiento para aplicaciones Wicket

[cobeete]

Hola, buenas.

Me gustaría saber si alguien ya ha pasado por esto antes y me puede echar una mano.

Estoy trabajando en un proyecto con arquitectura REST donde utilizamos Wicket para implementar el front-end. Desde "arriba" se está dudando si las estructuras de comunicación entre BE y FE son demasiado grandes en tamaño. Por ello estoy buscando alguna herramienta capaz de medir el rendimiento basándose tanto en el tamaño de la sesión como en el tiempo consumido a la vuelta de cada llamada para refrescar en la pantalla toda la información transportada dichas estructuras de comunicación.

Leyendo he encontrado algunas herramientas pero no estoy seguro si puedo utilizarlas dentro del framework de Wicket:

• Apache JMeter: por lo que he leído es de las completas. Pero dudo si puedo utilizarla puesto que nuestra aplicación Wicket genera las urls dinámicamente. También he leido algo sobre la posibilidad de pasar parámetros mediante expresiones regulares.
  
• YourKit: he leído poco aunque también comentan que es bastante completa. Además, he visto que se puede integrar con Eclipse/Spring IDE con un profiler pero aún no sé como se utiliza.
• Wicket Inspector: es una herramienta de desarrollo integrada en Wicket (org.apache.wicket.devutils). Si alguien la utilizado, ¿sabe si se adapta a mis necesidades?.

Si conocen alguna otra...

Muchas gracias de antemano,

Manuel Bordallo

[Ernesto Reinaldo Barreiro]

Hola.

2013/2/28 cobeete <manuelb...@gmail.com>

Hola, buenas.

Me gustaría saber si alguien ya ha pasado por esto antes y me puede echar una mano.

Estoy trabajando en un proyecto con arquitectura REST donde utilizamos Wicket para implementar el front-end. Desde "arriba" se está dudando si las estructuras de comunicación entre BE y FE son demasiado grandes en tamaño. Por ello estoy buscando alguna herramienta capaz de medir el rendimiento basándose tanto en el tamaño de la sesión como en el tiempo consumido a la vuelta de cada llamada para refrescar en la pantalla toda la información transportada dichas estructuras de comunicación.

FE=Front end? BE? 

A) Wicket es un consumidor de estos servicios REST? B) O utilizas wicket para implementar REST? Si es  A wicket consume estos servicios y despues renderiza lo que los usuaros ven? Esto es me parece muy costoso pues tienes la suma de dos latencias 1) leer los valores de REST 2) producir contenido HTML a partir de estos valores y transmitirlos al cliente.

Seria mas inteligente hacer consumir los servicos REST desde el cleinte mismo y producir la vista dinamicamente en el cliente (e.g. using ember, backbone, angular, http://knockoutjs.com/, o directament jquery).

 

 

Leyendo he encontrado algunas herramientas pero no estoy seguro si puedo utilizarlas dentro del framework de Wicket:

• Apache JMeter: por lo que he leído es de las completas. Pero dudo si puedo utilizarla puesto que nuestra aplicación Wicket genera las urls dinámicamente. También he leido algo sobre la posibilidad de pasar parámetros mediante expresiones regulares.
  
• YourKit: he leído poco aunque también comentan que es bastante completa. Además, he visto que se puede integrar con Eclipse/Spring IDE con un profiler pero aún no sé como se utiliza.
• Wicket Inspector: es una herramienta de desarrollo integrada en Wicket (org.apache.wicket.devutils). Si alguien la utilizado, ¿sabe si se adapta a mis necesidades?.

Esta herramienta es muy util a la hora de desarrollar. Tambien prodrias utilizar YSLOW para ver exactamente que estas trasmintiendo con cada request-cycle. 

 

Si conocen alguna otra...

Muchas gracias de antemano,

Manuel Bordallo

--
Has recibido este mensaje porque estás suscrito al grupo "wicket-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a wicket-es+...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a wick...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/wicket-es?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--

Regards - Ernesto Reinaldo Barreiro

Antilia Soft
http://antiliasoft.com/

[Marcelo Morales]

Tal vez convenga definir más precisamente los elementos de
comunicación entre FrontEnd y BackEnd. ¿Cúal es la arquitectura?

Asumamos que es (mobile browser) <-A-> (wicket node 1)<|B|>(wicket
node 2) <-C-> (rest service)

¿Consideramos el límite entre FE y BE <-A-> o <-C->?. Sólo lo pregunto
porque mencionas la arquitectura REST que no parece ser relevante y no
parece que quisieras medir "<-C->". Sólo coloco "<|B|>" y dos nodos
porque es el único elemento de comunicación que sufriría por el tamaño
de la sesión, que parece ser relevante.

Para medir la latencia y sesión de <-A->, recomendaría simplemente
subir el RequestLogger de Wicket, parsear y analizar el resultado.

Para hacer la medición del lado del cliente, puedes utilizar las
herramientas de desarrollo de chrome, netexport para firefox, o
debugbar para IE, exporta el archivo HAR y usa algo como
http://www.softwareishard.com/blog/har-viewer/ . Podrías correlacionar
el conjunto de peticiones con el logger que genera el RequestLogger.

Para medir "<|B|>". Entonces lo único que te conviene medir es la
comunicación multicast (digamos 228.0.0.4) + el puerto de replicación
(digamos TCP en el rango 4000-4100). ¿Tal vez unas cuantas instancias
de selenium?.

Sobre jmeter. No entendí cómo utilizarlo con CryptoMapper (que es
importante en mi entorno).

No he usado ni YourKit, ni Wicket Inspector.

Saludos

2013/2/28 cobeete <manuelb...@gmail.com>:

> --
> Has recibido este mensaje porque estás suscrito al grupo "wicket-es" de
> Grupos de Google.
> Para anular la suscripción a este grupo y dejar de recibir sus correos
> electrónicos, envía un correo electrónico a
> wicket-es+...@googlegroups.com.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> wick...@googlegroups.com.
> Visita este grupo en http://groups.google.com/group/wicket-es?hl=es.
> Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
>
>



--

Marcelo Morales