Understanding FastCGI and “Gotchas” with Running Native Code

Refer to Programming Windows Azure

In the early days of the Web, most web servers used Common Gateway Interface (CGI) programs to execute code on incoming requests, and return a response to the

user. Web servers would create a new process (typically Perl, or sometimes a shell), send it the incoming request through standard input, and read the results from the
process’s standard output.

However, launching a process on every request was a big drag on performance. Not only was creating a new process a heavyweight operation (and more so on Windows,

since NT has a different model for process creation than what Unix has), but having hundreds of these processes hanging around executing code would play havoc with

memory usage.

Web server developers knew this, of course. Two different solutions evolved to deal with the issue of heavyweight CGI processes.

The first is what has been referred to as the in-process module. This is the model followed by IIS with its ISAPI filters or its modules in IIS7. Here, the web server
process loads a library into its address space that “knows” how to execute code. This library typically implements an API specific to that web server (the IIS plug-in API, the
Apache module API, and so on). When a request comes in, the web server calls this library and executes the request. Since the library lives within the server process, there
is no expensive process setup/tear-down or communication to worry about.

The source of the speed is also the source of a few problems. Each web server typically has its own API, so these modules must be rewritten multiple times. Since the module lives within the server process, it can do whatever the server process does. A security exploit within one of these libraries can take over the web server. More importantly, a crash in the module will take down the web server as well.

FastCGI is an alternative to this model. In FastCGI, instead of the web server loading a module in-process, the web server communicates to a special FastCGI process,This
FastCGI process hosts the language runtime. Since it is a different process, any crashes or security vulnerabilities don’t affect the web server process. The FastCGI process is long-lived (that is, it isn’t restarted for each connection), so there is none of the process setup/tear-down overhead experienced with CGI. Best of all, FastCGI is an open
standard supported by all major web servers, so a wide variety of language implementations support it.

“Gotchas” with Running Native Code

When developing applications that use the native code techniques described in this chapter, be aware of the following common mistakes:

1. Remember that the Dev Fabric runs under your credentials on your local machine. If your operating system is 32-bit, the Dev Fabric will run in 32-bit mode. However, in the cloud, all 32-bit processes will be run in Wow64 mode, which can be different in subtle ways. Moreover, a 64-bit process cannot load a 32-bit DLL. One common mistake is to P/Invoke a 32-bit DLL and to upload the DLL to the cloud. Though it’ll work in the Dev Fabric running in 32-bit mode, it will fail in the cloud.
2. In the cloud, all code is run under a restricted user account. Any operations requiring administrative privileges will fail. Common operations such as launching
   msiexec or registering a COM component currently won’t work inside the Windows Azure virtual machine.
   

Note from envykok

Native code is machine code executed directly by the CPU. This is in contrast to .NET byte code, which is interpreted by the .NET virtual machine. Native code doesn't run on the Common Language Runtime (CLR).