Atlas, Carrying the Weight of the POSTBACK on His Shoulders?
At first glance and 2nd, 3rd, 4th clicks, this site looks really great:
http://asyncpostback.com/02_UpdatePanel/02_AtlasUpdatePanel.aspx
If you examine the browser/server conversation for the first request
and response with the Live HTTP Headers FireFox extension, you'll see
this:
GET /02_UpdatePanel/02_AtlasUpdatePanel.aspx HTTP/1.1
Host: asyncpostback.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4)
Gecko/20060508 Firefox/1.5.0.4
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
http://asyncpostback.com/02_UpdatePanel/02_AtlasUpdatePanel.aspx
HTTP/1.x 200 OK
Cache-Control: private
Content-Length: 62659
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Date: Wed, 28 Jun 2006 05:29:59 GMT
OK, Fine. Expected. 62 K for a first load. Not bad.
Now start clicking on column headers or the page numbers and watch the
Content-Length. It starts at about 8.5 k. Nice. But, then it grows, and
grows, and grows, and grows, and grows. It's everlasting.
When I did that about 300 times, the last post operation had a content
length of nearly 100,000.
http://asyncpostback.com/02_UpdatePanel/02_AtlasUpdatePanel.aspx
POST /02_UpdatePanel/02_AtlasUpdatePanel.aspx HTTP/1.1
Host: asyncpostback.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4)
Gecko/20060508 Firefox/1.5.0.4
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
delta: true
Cache-Control: no-cache, no-cache
Content-Length: 89381
Pragma: no-cache
ctl00$ScriptManager=c... 98,000 bytes on the POSTBACK, 98,000 bytes: Ya
take 1,000 down, Ya POST it BACK: 99,000 bytes on the POSTBACK
...DAv&
HTTP/1.x 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 98334
Content-Type: text/xml; charset=utf-8
Expires: -1
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Date: Wed, 28 Jun 2006 05:28:32 GMT
Is this a problem with the configuration for the element that asyncpostback.com is using the Atlas
UpdatePanel control? You can also use Fiddler to watch the requests. I think Fiddler is a bit slicker than Live HTTP Headers, obviously, so use that if you're testing in IE. It is definitely the ViewState parameter that grows and grows and grows, so this has to be configurable I hope.
-- Update --
When I tried this in my own project, I used this code:
<atlas:ScriptManager ID="ctlScriptManager" EnablePartialRendering="true" EnableViewState="false" runat="server" />
And then:
<atlas:UpdatePanel ID="ctlUpdatePanel" EnableViewState="false" runat="server" Mode="Conditional" RenderMode="Inline">
<ContentTemplate>
...
With view state disabled, the post size stays very small throughout the chain of request/response pairs. This is much better!
Thanks,
Josh