Home/ Questions/Q 6163829
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T21:53:29+00:00

I have a this asp.net page which upon first time load: 1: Make a

  • 0

I have a this asp.net page which upon first time load:

1: Make a DB call and get data – XML string (this chunk can go beyond 100kb). And this DB call is a bit expensive takes about 5-10 secs.

2: I loop through this XML and create a Custom Collection with values from XML. Then Bind it to a Repeater Control.

Now the repeater control has one text input. User is free to enter values in one or more or all TBs or leave all blank. Then then hit Save button.

On Save Postback, I will have to loop through all rows in the Repeater, Collect all the rows that has some input in the and generate an XML using the initial values and this new input value and Save it to DB.

Problem:
So I will need reference to all the initial XML values. I can think of these options and looking for inputs on selecting a best one.

1: ViewState: Store my Collection or XML string in ViewState – I’m sure it is will be too huge

2: Session: Use Session to store Collection of xml string – Again

3: DB Call: Make a DB call to get the data again – as I said it is kind of expensive call and my DBA is asking me to avoid this

4: HiddenField: Store the essential data from XML in to HiddenField and use that for Save manipulation. i.e. in each repeater item find all the hiddenfields

Which one is best in terms of better request response and less resource utilization on server?
Or is there a better way I am missing?

PS: Have to use ASP.NET 2.0 WebForms only.

Update1:

I tried the following with ViewState:

1: Store entire xml string: ViewState length = 97484 and FireBug shows pagesize – 162Kb

2:Store stripped down version of Collection with required only data: ViewState length = 27372 and FireBug shows pagesize – 94Kb and with gzip compression it reduces to 13kb.

With the existing website FireBug shows Size 236Kb.

So definitely option 2 is better and my new version is better then current website.
So any inputs?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A quick question – who is your target audience for this page? If it’s an internal website for a company then just storing the data in viewstate might be acceptable. If it’s for external people, e.g. potential customers, then speed and performance probably matter to you more.

    1. Viewstate – have you tried adding your XML to viewstate? How much did it increase the page size by? If you’re gzipping all of your pages rather than sending them over the wire uncompressed then you could see about a 70% reduction in size – 30kb isn’t that much these days…

    2. Session – it is worth remembering that the server can and will drop data from sessions if it runs out of space. They can also expire. Do you trust your users not to log in again in a new tab and then submit the page that they’ve had open for the last 10 hours? While using session results in less data on the wire you might need to re-pull the data from the db if the value does end up being dropped for whatever reason. Also, if you’re in a web farm environment etc there are complications involving synchronizing sessions across servers.

    3. DB Call – can the query be optimised in any way? Are the indices on all the fields that need them? Maybe you and your DBA can make it less painful to pull. But then again, if the data can change between you pulling it the first time and the user submitting their changes then you wouldn’t want to re-pull it, I suspect.

    4. Hidden Fields – With these you’d be saving less data than if you put the whole string in Viewstate. The page wouldn’t be depending on the state of the webserver like with session and nor would you be racing against other users changing the state of the db.

    On the whole, I think 4 is probably the best bet if you can afford to slow your pages down a little. Use Firebug/YSlow and compare how much data is transmitted before and after implementing 4.

    One final thought – how are things like this persisted between postbacks in the rest of your webapp? Assuming that you haven’t written the whole thing on your own/only just started it you might be able to find some clues as to how other developers in a similar situation solved the problem.

    Edit:

    there is a load-balancer, not sure how it will play with Session

    If you have a load balancer then you need to make sure that session state is stored in a state server or similar and not in the process (“inproc”). If the session is stored on the webserver then option 2 will play very badly with the load balancer.

    • 0