Fiddler herramienta de bolsillo para depurar trafico HTTP y mas...

¿De que me puede servir depurar tráfico http?. Veamos:

Podemos ver que llamadas a recursos no tienen respuesta, (pusiste elementos img, pero te olvidaste de subir las imágenes al server :S). Pero quizás la principal feature es ver a detalle el request y response. En la imagen para el request seleccionado, vemos cuantos bytes son enviados al servidor, y cuantos bytes recibimos del servidor. Esto nos puede ayudar sobretodo, cuando estamos buscando opciones de performance, con esto podemos ver a detalle, que esta generando que nuestra web tengo un tráfico de bytes demasiado alto. Otro cosa rápida y útil que podemos hacer es ver la ventajas de usar AJAX, por ejemplo este es el request/responde, cuando cambio de página en un gridView:

Como pueden ver en el response se vuelve a enviar todo el contenido de la página al cliente. Pero si por ejemplo ponemos nuestro GridView en un UpdatePanel, el responde sólo será del html que engloba al GridView, más no toda la página. Esta es una de las ventajas de usar AJAX, reduce el tráfico de nuestra web.

Y si queremos ser un poco mas extremos, podemos hacer llamadas desde JavaScript a Servicios Web. Como lo hace el control AutoComplete, del ASP.NET AJAX Toolkit:

Como pueden ver, lo que viaja es sólo información, ya en JavaScript se hace el trabajo de maquillaje de la información. Usar JavaScript con WebServices, es más limpio en cuanto al envió (modelo centrado en el cliente: data), pero también mas complejo ya que nosotros a través de javascript debemos dar la presentación a esa información. Con el UpdatePanel viaja información, pero también viaja la presentación (modelo centrado en el servidor: data+html).

Para leer un poco más sobre los modelos de programación de AJAX revisar: Atlas Programming Model. Pero resumiendo JavaScript+WS modelo centrado en el cliente, solo viaja información y a través de JavaScript recibimos la información y tenemos que darle presentación antes de mostrarlo al usuario a través de JavaScript; usando UpdatePanel modelo centrado en el servidor, viaja información más presentación, el servidor además de enviar la información también envía la presentación (elementos html). Para tomar la decisión de que modelo usar tenemos que examinar tiempo/tráfico, ¿Cuál es la prioridad: desarrollo para ayer o reducir a lo máximo el tráfico de la web?

Ya hable de AJAX sin querer :$, y la otra feature importante de Fiddler es poder grabar pruebas Web para Visual Team System for Tester:

Esto es importante sobre todo cuando tenemos que hacer pruebas web a aplicaciones que hacen uso de AJAX.

Web Site: http://www.fiddlertool.com
Title: Fiddler: Web Debugging Proxy
Description: Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
Download: Fiddler2 (536KB)

sergiot @ trujillo

Saludos,


Post cruzado
Published 6/2/2008 10:38 por Sergio Tarrillo
Comparte este post:
http://geeks.ms/blogs/sergiotarrillo/archive/2008/02/06/69504.aspx

Comentarios

# re: Fiddler herramienta de bolsillo para depurar trafico HTTP y mas...

Muy buen articulo Sergio, como siempre.

Solo una acotacion

"(..)si por ejemplo ponemos nuestro GridView en un UpdatePanel, el responde sólo será del html que engloba al GridView, más no toda la página(..)"

La idea es que desde el postback VA TODO, el ViewState completo de la pagina,  (hay maneras de que ni siquiera tenga que ir en la pagina pero eso es otro tema) y otras cosillas... es bueno darle una mirada a un postack de una respuesta... aqui coloco un ejemplo para los mas

curiosos...

Es bueno aclarar que donde dice:

   {repetir varias veces esto...muchas} va todo el kilometraje de Viewstate

ejemplo de una respuesta en crudo:

-----------------------------------

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

Date: Mon, 14 Jan 2008 18:31:25 GMT

X-Powered-By: ASP.NET

X-AspNet-Version: 2.0.50727

Transfer-Encoding: chunked

Cache-Control: private

Content-Type: text/plain; charset=utf-8

f7

217|updatePanel|UpdatePanel1|

                       {Contenido del Update panel...}

               |

7b8

1580

|hiddenField|__VIEWSTATE|zU5k+Fu81tpq{repetir varias veces

esto...muchas}=|0|hiddenField|__VIEWSTATEENCRYPTED||44|hiddenField|

__EVENTVALIDATION|OUCaGwN089p2eTR8qG{repetir varias veces esto...}=|0|

asyncPostBackControlIDs|||0|postBackControlIDs|||27|updatePanelIDs||

tUpdatePanel1,tUpdatePanel2|0|childUpdatePanelIDs|||12|

panelsToRefreshIDs||UpdatePanel1|2|asyncPostBackTimeout||90|23|

formAction||UpdatePanel_Basico.aspx|13|pageTitle||Untitled Page|

0

como veran devuelve text/plain y no text/html... ya que luego debera parsearlo en el cliente este lindo contenido.

Lo que va dentro de {Contenido del Update panel...} es lo que va a renderizar en el cliente (en el UP)

Thursday, February 7, 2008 12:35 AM por José A. Fernández

# re: Fiddler herramienta de bolsillo para depurar trafico HTTP y mas...

José, tienes razón la frase debió ser así: "(..)si por ejemplo ponemos nuestro GridView en un UpdatePanel, el response sólo será del html que engloba al GridView, más no el html del resto de controles o página [pero si viaja el ViewState](..)"

También como dices en el postback va todo, se ejecutan todos los eventos de la página, pero en el response sólo viene el html de los controles, que están dentro de un updatePanel, y tambien viaja el viewState de la página.

Esta entrada era base para la siguiente entrada hablar del ViewState y el UpdatePanel, pero eso será en la otra entrada.

Nos leemos, y gracias por tus aclaraciones.

Saludos,

Thursday, February 7, 2008 12:57 AM por Sergio Tarrillo

# Aplicaciones de Escritorio vs Aplicaciones Web, ??hay diferencia en el desarrollo? « advisorsystem

PingBack desde  Aplicaciones de Escritorio vs Aplicaciones Web, ??hay diferencia en el desarrollo?  « advisorsystem