Groups | Blog | Home
all groups > dotnet performance > june 2003 >

dotnet performance : ASP.NET Performance considerations



Cheung, Jeffrey Jing-Yen
6/30/2003 2:05:37 PM
I am somewhat proficient (very generous statement) in coding simple
ASP.NET applications and manipulating datasets, datatables via ADO.NET;
however, I am by no means an expert on what occurs behind the scenes and
what performance considerations should be taken while creating an
application. Consequently, one of the applications I've made
consistently deadlocks every night at around the midnight hours. Until
I generate a dump file, I realize that I will not be able to pinpoint
what exactly causes this behavior. I'm wondering if there is a general
site or any pointers you guys can give to help me out when trying to
program with performance in mind?

On a few appliactions that I've witnessed for sample and conceptual
analysis, I've seen the overuse of datasets, when datatables could be
used. Is creating a dataset object overkill on memory, or is the
difference negligble? Also, I've seen the explicit closing and opening
of connections when messing with data adapters via ADO.NET. Until
recently, I thought that this was normal, but I've been informed by
someone that this is indeed not the right way to go about things. I was
told that the Fill method of a DataAdapter will open and close the
connection as needed. Is this correct? And what consequences would I
face if I opened and closed the connection manually?

On a separate note, does anyone have any experience in debugging a crash
dump via the ASPNET worker process? I realize that if I don't download
the correct symbols, most of the debugger would be useless to me unless
I'm proficient in some sort of Machine Language ASM. Which symbols
would I need to import?

I appreciate any advice you can give.

Thanks in advance,

Jeff Cheung

Michael Giagnocavo [MVP]
6/30/2003 2:27:48 PM
[quoted text, click to view]

msdn.microsoft.com --- there are a few great articles on performance
with the CLR and how to get the most out of it, as well as
understanding how the GC works (important).

The BEST thing to do is test. Run tests on everything, as that's the
best way to find out what the REAL cost is. For high-precision, use
Kernel32.dll!QueryPerformanceCounter.

Also, the Performance Counters that .NET installs for use with the
Performance Monitor are great (see how many GCs have passed, how much
RAM/CPU used, etc.). As well, you might want to install a CLR
Profiler (there's one available at MSDN) to look into memory issues.

[quoted text, click to view]
opening

It will take some extra memory, but it's not overkill. If you have
500k of data, a few more bytes for the DataSet isn't going to make a
huge difference. An object costs 12 bytes + the bytes for its fields.
Looking at the DataSet class, I don't think it's a lot of memory.
However if you have a small amount of data, like only one row with a
few fields, then you might want to consider alternative ways of
sending the data, if it is a performance critical section.

[quoted text, click to view]

I believe if you open and close it manually, it should have a minimal
effect (it should only need to check the connectionstate). If you are
going to use it a few times in a row, you might want to leave it open.
Again, performance testing could show any real difference.

-mike
MVP

Cheung, Jeffrey Jing-Yen
6/30/2003 3:55:26 PM
Michael,

Thanks for the incredibly verbose and informative response.


[quoted text, click to view]
AddThis Social Bookmark Button