Scott Forsyth's WebLog

Upcoming Speaking Engagements

OWScott — Tue, 06 May 2008 03:47:00 GMT

There are some exciting events coming up around the Charlotte area which I'll be speaking at. Next weekend is the Charlotte Code Camp Spring 2008. I'll be speaking on what is currently fresh on my mind, and what I believe is very applicable to developers today. The session is titled "What every developer needs to know about IIS 7".

Here's the Code Camp agenda: http://www.developersguild.org/Default.aspx?tabid=248 For anyone in the area, I encourage you to register before it fills.

IIS 7 has many new changes that affect the developer this time around. With IIS 6, mostly just the server administrator benefited. But, with IIS 7, there are many changes that apply to the developer. There are deployment changes, web.config configuration changes, the new system.webServer which applies to all types of files, distributed configuration, better debugging and troubleshooting tools, new remote management tools and those are just the most obvious. The list goes on when you talk about the modular framework, extensibility, shared configuration for webfarms, security and FTP changes just to name a few. I'll be speaking this very topic.

The other event in this area is July 8th in Ashville. There is a new user group starting up next week, May 13th. (http://wncdotnet.com/) Brian Hitney will be presenting on "Building Next Generation Web Applications with VS2008" for the opening night. Dave Kolb asked if I would speak at one of the following events. I can't in June because I'll be at TechEd 2008, but I will for July 8th. Ashville is a beautiful area about 2 hours North of where I live so I'll take my wife and kids and stay the night. We're all looking forward to the trip. I'll be covering a similar session as I will at Code Camp.

Enabling XP and Windows Server 2003 to Search All Files Types

OWScott — Fri, 04 Apr 2008 14:34:00 GMT

Searching for file content on your computer or server is a common task and one where you would expect accurate results. You, like so many of us, may have assumed that but found different results.

Within Windows 2000 Server, if you entered something in the windows search dialog and clicked "Find", it would find it. But, with Windows Server 2003 or Windows XP, there are a lot of searches that would come up empty, even if you were sure that you had files with the words in them that you were searching for.

The reason that the results are different in Windows Server 2003 and Windows XP is because Microsoft decided to only include certain types of files in the search to speed up the search. Even if you set the file type as "All Files and Folders", it ignores a large amount of files when doing a search. The reasoning is that it takes a long time to search every file on the server and binary type files like a jpg or gif or exe don't need to be searched for a plain text search term. Why include them if they aren’t going to turn up any results anyway.

While I agree with it in part, if I want to find a file based on a keyword, I want it to search every file so that I can be sure that my search is accurate.

The fix is fairly easy as long as you don't mind making a registry change. My preferred method is to set Windows to index every file, even if it's an unknown exception. This is done by adding or changing a DWORD called FilterFilesWithUnknownExtensions in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex. Set it to 1. (1 for on, 0 for off)

In fact I added it as part of the build process here at ORCS Web when Windows Server 2003 first came out a few years ago. The search on every server on our network will search every file type.

Here is how I prefer to do it. Create a file called AddIndexingToAllFiles.reg (Or, I just call it abc.reg since I delete the file immediately after using it). Then put the following in it:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex]

"FilterFilesWithUnknownExtensions"=dword:00000001

Save the file on your desktop and double click on it. After accepting the prompt and warning, the entry will be added to your registry. You can delete the registry file since you're done applying it.

Here's a good Microsoft KB article on this with further details: http://support.microsoft.com/default.aspx?scid=KB;EN-US;309173. It also explains how you can add specific extensions rather than just indexing all files if you prefer to do that.

Note: This is for Windows XP and Windows Server 2003. The rules change again in Vista with a whole new search engine and method. Here is a long discussion between Microsoft and some not-so-happy people discussing how Vista works: http://windowsvistablog.com/blogs/windowsvista/pages/advanced-search-techniques.aspx.

tsadmin command change in Windows Server 2008

OWScott — Thu, 03 Apr 2008 16:18:00 GMT

I use Remote Desktop all the time to manage servers remotely, and often I join other people's sessions to troubleshoot something with them, or walk through something or other.

In Windows Server 2003 (and Windows 2000 Server), the easy way to start up Terminal Services Manager is Start -> Run -> 'tsadmin' -> [Enter]. This calls us Terminal Services Manager where I can right-click on a user and click 'Remote Control', and if they approve, I can join their session.

This doesn't work in Windows Server 2008 anymore. The change is ever so slight. In Windows Server 2003 the tool was tsadmin.exe, so typing 'tsadmin' was all that was required to start the tool. Now, in Windows Server 2008, this has been moved to a MMC snap-in and is called tsadmin.msc (plus tsadmin.dll is used silently).

So, to spin up Terminal Services Manager in Windows Server 2003, you can click on Start and your cursor focus will already be in the search box. Type 'tsadmin.msc' and press [Enter] and you'll be in Terminal Services Manager.

If you really don't want to type the '.msc' each time, you could create a batch file to do it for you. Create a file in c:\windows\system32 (which is in the system path already), call it tsadmin.bat and type 'tsadmin.msc' (without the quotes) in the body of the file. Save it and you'll be set. The disadvantage of doing this though is that you won't be practiced up on typing tsadmin.msc on fresh servers, so personally I prefer to just remember the extra .msc now on Windows Server 2008.

Note: If you don't type this often enough to remember 'tsadmin.msc', this has always been available from the Administrative Tools folder. In Windows Server 2003/2000 it's directly under Administrative Tools. In Windows Server 2008 it's one folder deeper under 'Terminal Services'.

IIS7 blocks viewing access to files in bin and other asp.net folders

OWScott — Wed, 05 Mar 2008 21:31:00 GMT

I was just asked to help someone troubleshoot a site that worked fine on Windows Server 2003 / IIS6 but didn't work on Windows Server 2008 / IIS7. A file was in a folder under the bin folder on the site and displayed an error when trying to view the page. The path looked something like this:

http://www.sitename.com/subfolder/bin/debug/file.xml

The subfolder wasn't marked as an application, although that doesn't really matter. The point is that since /bin/ was in the path somewhere, IIS7 wouldn't allow the file.xml to be displayed. It served up a 404.2 error saying file or directory not found.

404 - File or directory not found.

The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.

Since I knew that it worked in IIS6, I knew that it wasn't asp.net that was blocking it, so I looked in applicationHost.config and found the following under the <requestFiltering> section:

So, IIS7 now blocks those key folders and doesn't allow them to be seen. To the outside world, any page in any of these folders appears to not exist.

There may be times when you really do want to display the page, as in this particular case. Not to worry, it can be changed easily enough. This setting in on purpose though, so you usually shouldn't remove it for the whole site.

You can use AppCmd or do it manually from applicationHost.config or web.config. Since requestFiltering is allowed to be set at the site or folder level by default, it's probably best to set a web.config file in the folder that you want to allow.

To do this, create a web.config file in your folder and type or paste the following into it. I should look something like this:

<?xml version="1.0"?>
<configuration>
   <system.webServer>
       <security>
          <requestFiltering>
               <hiddenSegments>
                   <remove segment="bin" />
               </hiddenSegments>
           </requestFiltering>
       </security>
   </system.webServer>
</configuration>

If you want to make the change to your applicationHost.config file instead, you can do it by adding a location tag to the bottom of the file (well, almost the bottom - along with the other location tags) like this:

You can do this using AppCmd instead. Just drop to the command prompt and type the following: (Be sure to change the paths to the correct page before running this.)

C:\Windows\System32\inetsrv\appcmd.exe set config "sitename.com/subfolder/bin/debug" -section:system.webServer/security/requestFiltering /-hiddenSegments.[segment='bin']

After making this change, you will be able to view pages normally, even if they have /bin in the site path.

Professional IIS 7 - Best IIS 7.0 book

OWScott — Mon, 18 Feb 2008 17:41:00 GMT

The title is a bit biased since I co-authored the book, but Professional IIS 7 will be out in print within a couple weeks and I highly recommend picking up a copy!

I've had my head buried in this book for months—spending more time that I realized possible, but learning IIS 7 inside out and ultimately enjoying it. (Although I have to admit that sometimes at 4:00 in the morning, trying to hit deadlines, I'm not sure that I realized that I was enjoying it. :))

The book will be in bookstores and shipping online during the 2nd week of March 2008. You can order it directly from Wrox: http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470097825.html or from Amazon.com.

We had a great team of authors on this book, each writing in areas that they knew best, and all delivering excellent content that is both knowledgeable, but also practical, based on their experience. The author list is: Ken Schaefer, Jeff Cochran, Scott Forsyth, Rob Baugh, Mike Everest, Dennis Glendenning.

I wrote on application pool administration, remote delegation, webfarm management and configuration, programmatic configuration and administration and diagnostics and troubleshooting.

Be sure to pick up a copy and tell all of your IIS friends about it too!

Application vs. AppDomain

OWScott — Sun, 02 Sep 2007 14:21:00 GMT

A question was asked on a forum that I frequent which I thought was worth writting a blog about.

Q: What is the difference between an application and an Appdomain? I understand from my research so far that an Appdomain is a container within which ASPX runs and that Apppool is a process that starts the w3wp.exe worker process within which ASP applications run.

A: That's a good question. Here are some key differences:

An application is an IIS term, but it's one that ASP.NET utilizes. Essentially it creates a sandbox, or a set of boundaries to separate different sites, or parts of sites, from the others.
An AppDomain is a .NET term. (In IIS7, AppDomains play a larger role within IIS, but for the most part it's an ASP.NET term)
An AppDomain contains InProc session state (the default session state mode). So if an AppDomain is killed/recycled, all of your session state information will be lost. (if you are using the default InProc session state)
Applications can have multiple AppDomains in them although often times there is a one-to-one relationship between them.
In IIS6 and greater, there is the option of creating groups, or "pools" of applications that can be bundled together or separated; however the server administer decides. These are called Application Pools. Each app pool runs under its own w3wp.exe worker process.
In IIS, it's easy to see an application. A new website is a separate application and any subfolder can be marked as an application. When they are, the icon beside the folder turnes into a picture of some gears. By right-clicking on the folder, you have the option of marking a folder as an application or removing it as an application, if it already is one. Also, in IIS6, in the Application Pools section, you can see all of the applications and which app pool they live under.
ASP.NET, on the other hand, doesn't give much visibility into AppDomains, at least not from any visual tools. This is done behind the scenes. Programmatically you can create them, tear them down or see a list of all running AppDomains.
You can recycle an application from IIS. In IIS5, you can't do it directly unless you recycle the entire web server, but in IIS6 and greater, you can recycle the application pool that the application lives under. It will gracefully die off and a new application will start up to replace it. Or, to word it another way, another w3wp.exe worker process will be started and then the old one will die off after it completes any currently running page requests.
You can recycle an AppDomain in ASP.NET through the 'touch trick'. There are a few ways to do it, but the most straight forward is to edit your web.config file in notepad and add a space to an insignificant place. Then save the file. This will cause the AppDomain to recycle. This *does not* touch the IIS application though.
Recycling an AppDomain will come pretty close to starting ASP.NET fresh again for that particular ASP.NET application, so although it doesn't recycle the apppool, it can give ASP.NET a fresh start in many situations.

VS 2008 and .NET 3.5 Beta 2 released

OWScott — Thu, 26 Jul 2007 21:42:00 GMT

Beta 2 of VS 2008 and .NET 3.5 which was just released a few minutes ago and is available for download. I know I've been really quiet on my blog for a while. I'm still around, just haven't freed up my time enough to do the blogging that I know I should. I figured I would break my silence and mention this release.

http://weblogs.asp.net/scottgu/archive/2007/07/26/vs-2008-and-net-3-5-beta-2-released.aspx

Scott Guthrie's blog post is a must read. Some key features in VS 2008 and .NET 3.5 are:

- LINQ
- JavaScript IntelliSense and Debugging
- AJAX integrated
- Great CSS support
- Development can target different versions of the framework
- much more

Registry change for perfmon and PID data

OWScott — Tue, 20 Mar 2007 02:34:00 GMT

Perfmon is a great tool for mining performance data on a server and has a slew of objects and counters to expose most any type of data.

As nice as it is, there is one thing that can be difficult to do, and that is to view data for temporary objects. For example IIS worker processes only live until the next recycle or restart. If there are many worker processes on the server, the default view doesn't allow you to tell which is which.

Notice in the screenshot that there are three w3wp.exe worker processes on this server in the section on the right, but you can't tell from this view which belongs to which worker process.

A co-worker of mind pointed me to this great registry setting today that takes care of this. http://support.microsoft.com/kb/281884. Through a simple registry change, you can view the PID of each worker process within perfmon. It can be obtained without the registry change, but through extra effort.

As long as you know the PID, you can match it up to the app pool easily. In IIS6, you can use iisapp.vbs. In IIS7, you can use "appcmd list wp". Of course Task Manager is a key tool that is often used in parallel to show active PIDs, worker processes and various other real-time counters.

The registry change is quick and painless. In fact, after making the change, I closed the Add Counters windows in perfmon and opened it again and the PID was there immediately. No restart necessary.

If you want to save a click or two, you can follow the following steps instead of doing the change manually:

Take the following indented text and save to your desktop and call it showPID.reg.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance]
"ProcessNameFormat"=dword:00000002

Double click, acknowledge the prompt and you're done!

Disclaimer: Any changes to the registry needs to be done with an awareness of the impact. There is always the chance that some tool, or another administrator, needs this to be at the default setting. While it is safe in most environments, I can't be held liable for any negative impact that this change has.

1000MB is not 1GB

OWScott — Tue, 27 Feb 2007 14:12:00 GMT

I had an interesting situation come up yesterday that I thought would be worth writing about.

As a web host here at www.orcsweb.com, we offer disk space, but obviously need to set some type of limits. One of our clients had an allotment of 1,140 MB. (That is an odd number, but that's what it worked out to.) While working with him a couple of weeks ago, I checked his disk usage by right-clicking on the folder in windows explorer and clicking on properties. The space that it told me was 1.14GB, which I relayed on to the client. So far so good, it seemed that he was right at his limit.

Yesterday, an automated process checked the disk usage on his site, calculated his usage at 1,170MB and sent him an email asking for him to address the disk space or increase his allotment. He was confused, and rightfully so, because I had just told him that he was at 1.14GB, and he was confident that nothing was added since our conversation.

So, I started digging. I checked the database information which is what the script utilized and say that it has been at 1,170MB every day for a while. So, I pulled apart our automated script to see why it said 1,170MB but windows explorer/properties said 1.14GB. I even created a 5 line VBScript script using FileSystemObject to see what it returned, and sure enough, it returned 1,170MB. I was confused and looked at the numbers for a bit, then realized that I had overlooked the obvious. It's something I know well, but it didn't click at first.

1GB is actually 1024MB. It's not an even 1000. People will often say that it's 1000, but that's just a rounded number. In day to day situations, it may not even matter too much, people are often wondering about their usage in general terms, not something so precise. But, in this case, one number was under his limit and one was over his limit so it was important to figure out the issue.

Check it out: The size is actually 1,227,418,765bytes, so we'll take that divided by 1024 (for KB) divided by 1024 (for MB) and divided by 1024 (for GB). We get: 1.1431228. That matches the size of 1.14GB shown. Now, multiple that by 1024 and we get 1,170MB. The 24MB that was lost in rounding made a big different in this case!

So, nothing was wrong in the script, it calculated the information correctly, but from the windows explorer/properties view, the 1024 instead of 1000 made enough of a difference that it threw us off at first.

I was able to work out something on the disk space that worked for both of us and everyone is happy, plus this serves as a good reminder about the real difference between 1GB and 1000MB.

PowerShell Cheat Sheet

OWScott — Thu, 25 Jan 2007 21:50:00 GMT

Here's a must-have cheat sheet for PowerShell. Jeffrey Snover has put together an excellent doc that is well worth printing off and keeping handy for anyone working with PowerShell:

http://blogs.msdn.com/powershell/archive/2007/01/24/powershell-cheat-sheet.aspx

Clip - Saving command line and powershell output directly to the clipboard

OWScott — Sat, 16 Dec 2006 01:12:00 GMT

Every once in a while I run across something so simple, yet so powerful, that I wonder why I've never heard of it before. Today I came across one of those situations.

Within Windows Server 2003 and Vista, there is a command line and PowerShell parameter called "Clip". This allows you to output the command line results directly to the clipboard. This is great if you need to output a large result, or even if you want to save the hassle of selecting text and copying to the clipboard when you could have done it in a single step.

It's very simple, just pipe (|) to the CLIP command.

For example, let's say I want to get a list of all IP addresses on a Windows Server 2003 box. (the server has dozens of IP addresses) In the past I would often pipe the results to a text file and then open the text file and save the results to the clipboard. Not anymore! The command would be like this:

ipconfig /all | clip

Now I have the detailed ipconfig in my clipboard to be pasted wherever I want. This works with large files and large output too. Be careful of course that you don't try to CLIP a 1000MB file!

Here's the help for clip:

CLIP

Description:
Redirects output of command line tools to the Windows clipboard.
This text output can then be pasted into other programs.

Parameter List:
/? Displays this help message.

Examples:
DIR | CLIP Places a copy of the current directory
listing into the Windows clipboard.

CLIP < README.TXT Places a copy of the text from readme.txt
on to the Windows clipboard.

And yes, I used CLIP to capture that help information, like so: clip /? | clip

What about Windows XP users? CLIP was not included in Windows XP but you can get it easily enough. If you have access to a Vista or Windows Server 2003 computer, just copy the clip.exe file from C:\%windir%\system32 folder to your system32 folder. It will immediately work as expected.

Tool: Creating a custom MachineKey in ASP.NET

OWScott — Thu, 14 Dec 2006 05:24:00 GMT

There are many times when it is worthwhile to create a custom machineKey for your web.config file. This is worthwhile on a webfarm but also worthwhile on a stand-alone server so that your machineKey remains the same after an iisreset or application pool recycle.

I've put together a simple tool that will generate a valid random machine key. It will create a validationKey and decryptionKey which you can copy and paste into your web.config file. This is random so there is virtually no chance of anyone else having the same keys.

I hope you enjoy!

http://www.orcsweb.com/articles/aspnetmachinekey.aspx

Vista and RDP6.0's Remote Desktop Prompt

OWScott — Fri, 10 Nov 2006 14:50:00 GMT

I use Remote Desktop Client dozens of times per day to administer remote servers. With Windows Vista, I get an ugly prompt when connecting to Windows Server 2003 and Windows 2000 Server machines saying:

Remote Desktop cannot verify the identity of the computer you want to connect to. This problem can occur if:

1) The remote computer is running a version of Windows that is earlier than Windows Vista.
2) The remote computer is configured to support only the RDP security layer.

Contact your network administrator or the owner of the remote computer for assistance.

Do you want to connect anyway?

I know that the remote server is good, it's in a memorized list of servers. But it is Windows Server 2003 or Windows 2000 Server. Although the prompt is correct, I don't want to have to acknowledge that prompt over and over again.

Note: (added later) The obvious answer that I was alerted to from a comment from Blandname is to do this per session: click on the advanced tab in the Remote Desktop Connection tool and change the Authentication options to "Always connection, even if authentication fails". If you create your own RDP file, you can set it with "authentication level:i:0."

If you want to set this at the server level or find out more about this setting, read on.

I did some digging using Process Monitor from www.sysinternals.com (recently acquired by Microsoft) and found that the mstsc process was checking for some particular keys in the registry. Two of them seemed possible candidates and after testing I confirmed that AuthenticationLevelOverride is the key that applies to this situation.

The registry key is a DWORD value at \\HKCU\Software\Microsoft\Terminal Server Client\AuthenticationLevelOverride

I googled on AuthenticationLevelOverride and couldn't find very much information. But one article had a fair bit of information: http://support.microsoft.com/kb/895433. Here are the 3 possible values, at least in Windows Server 2003:

Set the authentication level value to one of the following values:

•	0 This value corresponds to "No authentication."
•	1 This value corresponds to "Require authentication."
•	2 This value corresponds to "Attempt authentication."

I experimented and found that 2 is the default now. I tested the 3 modes and found that:

0 -> Doesn't prompt. Yah!
1 -> Gives a similar message but doesn't allow me to continue. This is the strictest.
2 -> Gives the message but allows me to accept and continue.

In my case, I don't even want the prompt so I set AuthenticationLevelOverride to 0 and I'm able to log into my Remote Desktop sessions without that extra prompt.

Warning: this is a decrease in security so should only be changed if you are aware of the what and why of this change.

In summary, if you want to remove the Authentication check on Windows Vista that prompts you every time you connect to a pre-Vista machine, add a DWORD registry entry called AuthenticationLevelOverride in the \\HKLM\Software\Microsoft\Terminal Server Client\ key and ensure that its value is set to 0.

Is 64-bit computing always better?

OWScott — Wed, 08 Nov 2006 04:01:00 GMT

In the early days of 64-bit, drivers were hard to find or unstable, programs wouldn’t run and help was scarce. I started using Windows XP 64-bit about a year ago, so I’ve battled through many of the issues with working with this ‘newer’ technology. At ORCS Web, we support Windows Server 2003 64-bit on different types of applications, from SQL Server to IIS to Microsoft Virtual Server.

So, is there a rule of thumb with 64-bit? Should everyone use it whenever possible? Or are there reasons to stick with 32-bit?

My original thought was that [64-bit = newer therefore 64-bit = better]. I’ve come to find out that isn’t always the case, as I’ll explain below.

First, my experience on a desktop.

I got a new computer built and supported by Dell as a 64-bit server and with Windows XP 64-bit pre-installed. Drivers weren’t a problem for me since Dell took care of that already. But I still ran into a number of issues, including:

Many applications didn’t work in 64-bit. Many of my favorite utilities and tools wouldn’t work. If I were to guess at a number, 80% of my applications worked like normal, but about 20% didn’t. That 20% was enough to be inconvenient.
My memory (RAM) usage was higher. For lots of smaller applications, there is a lot of waste. The full 64-bit address space isn’t always utilized, leaving lots of underutilized memory.
Help was hard to find. Even simple things like finding my Mail icon in the control panel took a long time to figure out: http://weblogs.asp.net/owscott/archive/2006/01/19/435921.aspx

So, I have come to conclude that in many cases 64-bit isn’t necessary for a desktop computer. My desktop has 3GB of RAM now, but I don’t see any advantages of using 64-bit unless I’m a developer that needs to test 64-bit applications or have a need to use very large amounts of memory. My general recommendation is to only use 64-bit for a desktop computer if you have a specific reason to do so.

Next, my experience on a server

How about on the server end? I made the same incorrect assumption at first, determining that most new servers would eventually use 64-bit as a standard. But experience and recent load testing has convinced me otherwise.

Recently we had a high-traffic ASP.NET website that we deployed on a 64-bit server with Windows Server 2003 x64 Standard Edition. It was part of a webfarm so we were able to compare it directly against other 32-bit servers with similar hardware. Performance was noticeably less than on the 32-bit servers which surprised me at first. I spent a consideration amount of time reproducing the issue and isolating it to just 32-bit. In fact, I tested ASP.NET and IIS6 running in 32-bit mode as well to test all three situations.

I did some load testing using Microsoft’s Web Application Stress Tool (WAST). I used 2 identical servers (ordered from Dell at the same time with the same specs) and built one as 32-bit and one as 64-bit. They are solid machines, Dual 3.0Ghz Dual Core CPU with 4GB of RAM and 15,000RPM SCSI hard drives. I set up 7 load testing servers using a Gbps network core to test.

Test Results – IIS only

Hitting IIS directly for a static 2kb page, both servers were able to serve up over 14,000 Pages/sec with only 70% CPU. The 7 load testing servers weren’t able to max out the web servers. So IIS doesn’t have any problem handling huge amounts of traffic!

Test Results – Simple ASP.NET

I then tested a simple ASP.NET page that ran <%= now %> as well as 2kb of plain text. The 32-bit server was able to serve up a maximum of 3,400 Pages/sec. The CPUs were the bottleneck. The 64-bit server was able to serve up a maximum of 2,100 Pages/sec. So the 32-bit server easily outperformed the 64-bit server. (Note: On this particular test, on the 64-bit server, ASP.NET and IIS performed the same whether they were in 64-bit mode or 32-bit mode.)

Test Results – ASP.NET loop

The next test was a While loop with 1,000,000 iterations. In each iteration I outputted Response.Write(“”) just to give it something to do. Both servers were able to serve up 68 Pages/sec. So, in this particular test, the 64-bit server was able to catch up in performance. It would appear that a while loop performs identical in both situations.

Test Result – Others

I ran some other tests, some with interesting unexpected data, but that is a whole different topic. These tests only start to dive into the differences between 32-bit and 64-bit computing, but they show that there is a substantial difference between them, and for low memory applications, a 32-bit Operating System is often faster.

From the other tests I performed, I concluded that there is about a 10 – 15% performance penalty running a 64-bit OS with low amounts of memory. This varies depending on what operation is being performed.

So, for the server environment also, I concluded that 64-bit isn’t always better either.

Now, what about the stories of huge performance gains on 64-bit? Believe them! J For high memory situations and products well tuned for 64-bit like SQL Server 2005, there are tremendous performance gains to be had. I’ve seen some pretty impressive tests show substantial performance gains on 64-bit. The 64-bit SQL Server and 64-bit Virtual Server servers that we have set up at ORCS Web (www.orcsweb.com) are handling huge loads with ease. While I haven’t purposefully compared SQL Server performance like I have ASP.NET, I have every reason to believe that the reports are true that under high memory demands SQL Server on 64-bit greatly outperforms 32-bit.

Memory limits blown away

If you have high memory requirements, 64-bit may not only be better, but it may be the only option. The 64-bit memory space blows away many of the memory limits that used to exist. We’re talking Terabytes instead of Gigabytes!

Summary

I’ve come to conclude that 64-bit isn’t always better. Don’t just use 64-bit to use the latest technology. For low memory situations, 64-bit may actually perform worse, have driver compatibility issues and be harder to support. But, for high memory situations, chances are good that those issues disappear and the benefits that the larger memory namespace offers will far outweigh the issues.

There is a place for each, but there is still a lot of life left for 32-bit computing.

Podcast interview on ASP.NET Podcast Show

OWScott — Wed, 23 Aug 2006 16:44:00 GMT

When Wally McClure came to Charlotte to give a talk on Atlas to the Charlotte User Group, I had an interview with him which is now live on Show #66 of the ASP.NET Podcast Show. I didn't dive in too deep, but we discussed Webfarm hosting and some of the topics I covered in my TechEd 2006 talk in Boston, and some of the new upcoming features in IIS 7.0.

Check it out:

http://aspnetpodcast.com/CS11/blogs/asp.net_podcast/archive/2006/08/17/504.aspx