Thanks for your response Hermawih,
For the "AutowireupEvent" attribute, you do not need to care it too much,
just keep the default setting. The double event handler registering will
occur only when you are developing ASP.NET page through VB.NET code(since
VB.NET will register event handler in the eventhandler's declartion code
also).
As for the following things you mentioned
=====================
also was given this advice somewhere.
But It is not clear to me what kind situations that I should choose one
over another.
I can't find yet a detail discussion about this. Let me make a wild guess.
I think most important things to consider are:
A1. The number of people connected to the server.
A2. How long the people will be connected to the server on average.
A3. How large the size of the data to cache. ( That is why you mentioned
about the size of description field )
If there are many people connect to the server and on average they stay
long
then I should choose direct connection to the server because in this
scenario
it will use much memory. But if few people connect to the server then I
should choose
caching. Can I say that?
=======================
My understanding is as below:
For ASP.NET server-side application's performance, generally, we would care
serveral things, they are response time, throughput and stability.
** response time will be affected by your page's processing time, and the
page's response content size. For example, if a page contains a long-time
data base accessing operation, the response time will be long also. Or if
the page's response content size is large(contains large viewstate or
content in page), it will also make the response time large. That's why it
is recommended that we try shrink the page size or avoid using viewstate
if possible.
**For page throughput, it also some want related to the response time.
Because all the ASP.NET requests are processed by thread-pool thread picked
up from threadpool. and for each process, it has only one .NET managed
threadpool and the max allowed nubmer of threads. So when those pooled
threads are all used(by some long-run task), other sequential requests will
be pending and affect the entire application's throughput. Here is a good
webcast introducing ASP.NET threading:
#Support WebCast: Microsoft ASP.NET Threading
http://support.microsoft.com/kb/820913/en-us
**For stability, mostly it is determined by some of the performance status
of the application. Such as memory usage, pending requests or deadlocks....
There is settings(for IIS6, it is in the application pool) indicate when
the number exceed certain limitation ASP.NET application process will be
recycled.
You can review the performance of your application based on these basic
rules together with those best practice aricles you can find in MSDN
library.
Hope this helps further.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.