Running Web Connection on Windows Server 2008 64 Bit

I just got done upgrading my live Web Server to a new high powered 64 Bit server. The old machine was getting a little bit long in the tooth with its classic Pentium 4 and meager 1 gig configuration. It's actually surprising just how well this old box handled the variety of traffic and volume handled by this site.

I decided to get a fairly powerful new machine: A quad Xeon (2.5ghz), with 8 gigs and 2 high speed 10k boot and drives plus a separate backup drive. Compared to the old box this machine is an incredible screamer and quite a few folks have commented of how performance has improved noticeably  since the upgrade. It's not just on the outside end but also on the backside end that this is a huge improvement - in the past the biggest bottleneck on the machine was a few Web Connection queries that are very slow and were often overwhelming the single CPU. The new quad CPU's give these requests considerably more breathing room as they don't tie up the only  processor and also because the queries themselves run significantly faster due to the new drives and faster clock-speed.

32 Bit Mode for Application Pools in IIS 7 - Yeah!

Anyhow, in the process of getting the new machine I also switched to Windows Server 2008 64 bit. I was a little wary about making this switch primarily because I was worried about my Web Connection applications that are running a 32 bit ISAPI DLL and 32 bit Visual FoxPro. Most of the other apps on the site are ASP.NET and can and do run now natively in 64 bit.

In IIS 5/6 that would have been a fatal issue given that IIS 6 and 5 required that the Web server is switched into 32 bit mode entirely in order to run ANY 32 bit applications, like my ISAPI assembly. It turns out IIS 7 makes this process much more granular with the ability to switch an IIS Application Pool into 32 Bit mode rather than the entire Web Server (IIS5/6):

That 'little detail' right there addressed my biggest concern about the Web Connection apps running on the 64 bit version of Windows Server.

I hooked up this Application Pool in the original test builds of the OS I had created and ran a two day load test on the existing  Web Connection sites and the apps chugged away at outrageous speed on this hardware mind you and without any hiccups. Looks like the 32 bit apps (Web Connection ISAPI + Visual FoxPro COM) will have no issues whatsoever on the 64 bit server (These informal tests BTW, managed nearly 200 Web Connection requests a second!).

The new quad processor is going to help some of the Web Connection Apps tremendously too. There are a few rather slow requests that have been chugging up the CPU to near 100% levels at times for a handful of particularly long queries, but with the quad these queries will no longer hold the entire machine at ransom. Testing those particular scenarios resulted in smooth operations which solves yet another issue that has been the cause of occasional server lockups in the past.

FWIW, the same approach can also be used for other VFP applications running inside of IIS. For example if you VFP COM objects running in ASP or ASP.NET those applications also have to switch to 32 bit mode. Most applications that use ISAPI or ISAPI filters and haven't been specifically re-written to support 64 bit too need to run 32bit as well.

A few small Hiccups

This process is indeed working out great with one exception: I had a few Web Connection requests running on the root site. There are about 5 pages that run on the root and because I've set up the root site without 32 bit compatibility these request are now failing.

I can't change the root site to 32 bit tough because this would affect several other applications that are now running in integrated mode at the 'root' level. So switching to 32 bit mode is not an option.

My solution to this problem was to create map the Web Connection Script Maps to ASP classic and then redirect the requests to a location inside of a Web Connection virtual. So I effectively moved the script files from /westwindnews.wst to /wconnect/westwindnews.wst and have the original URLs redirected to this new location.

To do this there's the ASP classic mapping:

I then create an ASP page that does the following:

<%

  Response.Redirect("/wconnect/westwindnews.wst")

%>

The redirected URL is in another virtual that does have the 32 bit flag set and can also process this extension.

I realize this is pretty ugly but it works to effectively let me run all of my Web Conection code in one place.

So why not use the Managed Module?

Starting with Web Connection 5.0 there's a Web Connection Managed Module that can run natively in 64 Bit (or 32 bit) in IIS 7 using integrated mode. This .NET module is written from the ground up in .NET code and provides functionally the same behavior (plus a number of additional features) as the ISAPI DLL.

Unfortunately due to the way the apps are set up on my server I am not able to run the new module. The issue is that I have one COM server that services 8 different virtual directories/applications. One limitation the .NET module is that each virtual directory is effectively its own AppDomain (.NET 'internal' process) and so each virtual is independent and can't interact with another's internal structures. The module manages the Web Connection Server COM object pool but each would get its own COM pool instance and so end up creating their own instances.

A workaround for this would be to consolidate all applications under a single virtual (not often possible), use file based messaging (which works fine across virtuals) or allow apps to run their own server instances.

Neither of these options would have been effective in my case and would have required quite a bit of reworking. So, instead I stuck with the easy solution of continuing to use the ISAPI extension which can run across multiple virtuals and so manage multiple applications with a single COM pool and that's working out just fine now.

No fear of IIS 7 and 64 bit

So the good news is that on Windows Server 2008 at least, running Web Connection apps in 64 bit is no problem. With the 32 bit flag for the Application Pool it's possible to get your existing apps up and running with practically no changes at all, which is good news given that much of the new server hardware that's coming out as well as the server software is more and more geared towards 64 bit computing.

It's good to know that Web Connection and VFP is ready and that it works well and reliably. The new server's been now up for one week and the crash and restart numbers that were somewhat frequent on the old server have diminished to almost zero - the extra horse power and memory are certainly helping to make the apps more stable.