« August 2004 | Main | October 2004 »
September 22, 2004
ASP.NET Performance
Since we have had some major issues recently regarding ASP.NET performance, I'll share some of the solutions I found. There are two major settings within the <processModel> node of the .NET machine.config: maxWorkerThreads and maxIoThreads. If you are running a web farm these could be set at the machine.config for easy deployment, or they may be set at a Web.config level. The maxWorkerThreads and maxIoThreads setting are threads per processor. So if the machine has 4 processors and the maxWorkerThreads=100, the following will be true: 4 * maxWorkerThreads will result in 400 max total threads. Microsoft recommeds you set both of the settings to 100. It is unknown if the the runtime will actually use that many threads. I also imagine that theses are logical threads and not physical threads.
The second machine.config node is the <httpRuntime>. The settings that should be changed are: minFreeThreads and minLocalRequestFreeThreads. If there are not minFreeThreads available to ASP.NET, the request will be queued and executed when they become available. MS recomeneds you set these to the following:
* minFreeThreads parameter to 88*N (N=CPUs)
* minLocalRequestFreeThreads parameter to 76*N (N=CPUs)
Another frequently misunderstood setting it the webGarden setting. This implies one aspnet_wp worker process per CPU if the setting is true (IIS 6). Web gardening has some side effects that you should be aware of:
* If your application uses session state, it must choose an out-of-process provider (NT Service or SQL).
* Application state and application statics are per process, not per computer.
* Caching is per process, not per computer.
[1] Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
[2] webGarden setting for multi-processor machine
[3] Using the ASP.NET Process Model
Posted by 0xFF3300 at 09:34 AM | Comments (0) | TrackBack
September 17, 2004
Motorcycling at the Playground
Posted by 0xFF3300 at 08:22 PM | Comments (0) | TrackBack
2 Connection Strings = 2 Connection Pools
I always wondered about this situation, if my app has 2 different connection strings will it have 2 different connection pools? The answer is yes, .NET checks if the connection strings are an *exact* match, if not it creates a new connection pool.
"When a connection is opened for the first time a connection pool is created and the pool is determined by the exact match of the connection string in the connection. Each connection pool is associated with a distinct connection string. When a new connection is requested, if the connection string is not an exact match to an existing pool, a new pool is created."
Posted by 0xFF3300 at 01:16 PM | Comments (0) | TrackBack
September 10, 2004
Soap over UDP
Well this spec is interesting, I feel the applications may be a little limited, but nonetheless interesting. UDP is much less expensive than HTTP, however datagrams are not guaranteed to reach their destination. An interesting specification definitely.
Posted by 0xFF3300 at 06:12 PM | Comments (0) | TrackBack
September 04, 2004
Disk Cloning with dd and netcat
I'm coming up with a solution to clone my root hard drive and I came across this article . Although dd is primitive, it defintley gets the job done and can copy across the network.- GNU utilities for Win32. http://unxutils.sourceforge.net/
- netcat for Windows. http://www.l0pht.com/~weld/netcat
- First Attempt at Creating a Bootable Live Filesystem on a CDROM http://www.linuxgazette.com/issue54/nielsen.html
- Good Site for Windows utilities such as newsid.exe: http://www.sysinternals.com
- Modifying ISO image http://www.winiso.com
- Solaris Bootable CD creation: http://www.lka.ch/projects/solcdburn/solcdburn.html
- Sun Blueprint: http://www.sun.com/software/solutions/blueprints/0301/BuildBoot.pdf
- Linux on Floppy: http://www.toms.net/rb/
- Static binaries for Linux.
Posted by 0xFF3300 at 01:21 PM | Comments (0) | TrackBack