Hi All,

I have a question about where to put entity's that I am working with during web postbacks. I have built a number of small intranet apps and have always used session variables to store things. My total number of users has always been small(200-500 total, 5-30 at most concurrent). If I have a form where a user is editing some entity and that edit cycle takes multiple postbacks I have always put the entity in session state untill the edit is complete or cancelled. Depending on the action they take, I always go back and null out the session variable. That has always worked for me in the past without any problems but now I am creating my first true public site and it has the potential to be large(1000+ total, 100-300 concurrent users or even bigger as word grows). Right now it is small and fits the model I am use too so I have been coding it in my same session state style but my concerns are for future growth is it better to use view state? or do you just always go back to the database for your entities during each postback. I just want to make sure that I start down the right path from the beginning so I don't have to do major refactoring one day if the site gets bigger.

Thanks,

Frank

The HnD project is a good starting place for a heavly used site. The logical layers are sperated. The system also relys on cache to store "static" data (data that does not change often). When it does change update db, clear cache. next time around load into cache if it's not present.

My rule of thumb for web app variables:

• specific to the forms instance: ViewState
• specific to the users instance: Session
• specific to the systems instance: CacheYour biggest preformance gains will come from async tasks and IAysncHttpHandlers. In general, async operations should be used when quering the db, and reading/writing files. This is an advanced task, so if it's new to you, start with small opertions and go from their. This will not increase individual user through put. What it will do is allow a great number of users to hit the site simultaneously. thus reducing the chance of a thread pool crash.

If you load large objects look into ASHX files to load the data instead of an aspx file. This is useful if you want to stream pictures/files to the browser. ASHX doesn't have the overhead of a web form, it simply makes an asp.net request, you control the response content.

When appropiate use the KeppConnectionOpen = true option and execute a series of queries against the db. This way your not continually opening a closing conections durning a single post back.

Thanks Jason,

I never thought about looking at the code for HnD, I will try that. Now when you say Async calls do you mean showing a "please wait while processing" page until the query is done and then show the results or are you talking about ajax stuff?

Thanks,

Frank

No, not AJAX (that's more pretty GUI stuff). Async commands are processes that are executed on a sperate thread. They are totally seperate from the default thread pool in IIS (I think). This is useful for large tasks when the thread is waiting for the routine to finish.

The most common examples are writing a file, reading a file, querying a database and calling a webservice.

There are a few different methods to execute async tasks.
1. The BackgroundWorker class. this is used more with desktop apps in relation to GUI changes, but could be used in web app without the GUI interaction.
2. There are System.Web.Page.AsyncTasks objects. These take serial commands and execute them in parallel. At least that's my understanding.
3. Some objects have async tasks built in like StreamReader.Begin/EndRead(); StreamWriter.Begin/EndWrite(); and SqlCommand.Begin/EndExecute(); I assume since your using LLBL you wouldn't be calling SqlCommand directly, but the concept is there. 4. IAsyncHttpHandler is the method I have used. in it's simplest form it's an ASHX file that inherits the IAsyncHttpHandler interface. I used this method to export a crystal report to a pdf file and stream the pdf file back to the browser. The same methodology can be used to display images. Loading images is the most common example.

To me, the biggest difference between synchronis and asynchronis calls is asynchronis requires a delegate to execute when the operation finishes. granted must more is happening and debugging is that must more difficult, but that's the first difference I noticed. here is a simple example (a picture would be better, but I'm not an artists).

synchronis operation 1. user visits site (request made) 2. excute some simple tasks/logic 3. query database 4. wait 5. read xml file 6. wait 7. compile page 8. send response to client (the wait symbolizes a long running process)

asynchronis operation 1. user visits site (request made) 2. excute some simple tasks/logic 3. begin query database 4. begin read xml file 5. end query database 6. end read xml file 7. compile page 8. send response to client while this is the same number of steps the main thread created 2 child threads: 1 to query the db and a 2nd to read the xml file. between the begin and end tasks the thread was returned to thread pool so another request could use it. when the child threads were completed a main thread (from iis thread pool) was used to complete the task.

Again, async tasks don't speed up individual requests for a given user (it will still take 500 milliseconds to complete the request). Instead it allows multiple users to make requests at the same time (1,000 people can make a request, before crashing the IIS server instead of 100 people).

a quick google search for AsyncTask, aspx, asp.net, or IAsyncHttpHandler should be a good starting point, if you want to persue this further.

Hi Jason,

Thanks again for your replies, they were very helpful. I have done threading in a windows app before without any problems but couldn't see how to do it in the stateless web enviroment.

Thanks,

Frank