rick.james

IIS 7 C++ Module API Sample: Controlling http.sys caching

rickjames — Tue, 20 Nov 2007 19:29:00 GMT

IIS 7 C++ Module API Sample: Controlling http.sys caching

Introduction

In my previous post we saw that http.sys caching can be very useful for high traffic (gigabits/sec) sites. In this post we create a sample module that allows configuring which URLs can enter the cache.

Code

There is very little non-template, IIS-specific, code in this module. In fact here is everything that is important:

REQUEST_NOTIFICATION_STATUS
MODULE::OnSendResponse(
    IHttpContext*           pContext,
    ISendResponseProvider*  pProvider
)
{
    if( !pProvider->GetHeadersBeingSent( ) )
    {
        //
        // headers not being sent, not first send response notification, nothing to do
        //
        goto Finished;
    }

    if( !g_pUrlHash->Exists( pContext->GetScriptName( ) ) )
    {
        //
        // not a pre-determined "hot" url, no caching..
        //
        IHttpResponse* pResponse = pContext->GetResponse( );
        pResponse->DisableKernelCache( 123 );
    }

Finished:

    return RQ_NOTIFICATION_CONTINUE;
}

Important points:

RQ_SEND_RESPONSE is a "non-deterministic" notification that can fire multiple times (e.g. whenever someone calls IHttpResponse::Flush). To determine the first time we're being notified, the module checks ISendResponseProvider::GetHeadersBeingSent. This is only true on the first notification for the request.
IHttpContext::GetScriptName is often the URL you want to compare to. It has been "sanitized" and had PATH_INFO removed.
IHttpResponse::DisableKernelCache trumps any cache policy configured with IHttpResponse::GetRawHttpResponse()->...

Setup

As mentioned, there are many caches and caching algorithms in IIS. To simplify the testing of this module I:

disabled my file cache module (simply removed it from the pipline - "appcmd uninstall module FileCacheModule").
disabled the "hotness" detection algorithm in iiscore ("appcmd set config -section:serverRuntime -frequentHitThreshold:1")

Test

This time I'm using a newer dual-core machine with 1GB ram and running the perf client locally. There are 4000x184kb "hot" files, and 4000x184kb "cold" files. Total = 8000x184kb = 1.4GB. Hot files are hit 32x more frequently than cold files. For the Cacheit test, I installed the module and only gave it the full list of 4000 hot URLs.

Test	Req/s	Cache Content
		Hot	Cold
Baseline	770	3994	765
Cacheit	833 (+8%)	4001	13

Request/sec came from wcat's log. Cache contents was determined by running "netsh http show cachestate > out.txt" and then "findstr /i hot out.txt" and "findstr /i cold out.txt".

Conclusion

The optimistic conclusion is that we've learnt about a new way of using the module APIs as well as tried out a common thought experiment (what would happen if my cache new exactly what to cache). Another conclusion is that, with the exact scenario under consideration, there are probably very very few cases where this would be useful.

Fun with http.sys Caching

rickjames — Thu, 01 Nov 2007 16:40:00 GMT

Introduction

There are many caches available to web applications. Today I will play with the http.sys URI cache. It is a simple, fast, kernel-mode cache.

How it Works

First IIS must decide if the response can be stored in the http.sys' cache (devs: See HttpSendHttpResponse's pCachePolicy argument). There are about twenty reasons for IIS to decide something should not get in the cache (because of the cache's simple design). To find out why a specific request is not being cached, enable "Failed Request Tracing" and look for the HTTPSYS_CACHEABLE event's reason field.

Assuming the response meets the approx. twenty conditions, then IIS needs to decide if the item is "hot". Hotness can be configured using system.webServer/serverRuntime@frequentHitThreshold and frequentHitTimePeriod. A request is "hot" if it has been hit frequentHitThreshold times in the last frequentHitTimePeriod seconds. IIS only marks "hot" requests for caching.

Once IIS tells http.sys to cache, http.sys than applies some additional checks (settings), including a size limit, that defaults to 256kb. http.sys clears out entries that have not been accessed in UriScavengerPeriod (2 minutes by default).

Experiment

Using wcat, the attached wcat script and the attach content-creation script, I produced these results (using an old 1x dual-core machine):

Size	Cache Disabled		Cache Enabled		Percent Difference
	req/s	CPU	req/s	CPU	req/s	CPU
1,000 x 1kb	4960	100	38,041	100	+667%	0%
1,000 x 100kb	2383	100	3,514	50	+47%	-50%
100 x 10mb	35.72	81	35.5	52	-1%	-29%

Note: Generally it's a good idea to get CPU usage=100% in perf tests, but in this case I ran out of NICs at 3 Gigabits/sec

Summary

If you're serving megabytes/sec of static files, then you'll probably see some substantial performance improvements from http.sys caching.
Sometimes IIS 7 Output Caching allows you to put dynamically generated responses in http.sys' cache.

FastCGI: Debugging "The FastCGI process exited unexpectedly"

rickjames — Tue, 16 Oct 2007 15:37:00 GMT

FastCGI: Debugging "The FastCGI process exited unexpectedly"

Update 17-Oct: Added .lines, fixed some spelling mistakes, added pageheap Here is the sequence of events for two back-to-back FastCGI requests to a freshly started worker process:

Request 1: HTTP GET /hello.php
IIS (iiscore.dll) looks up handler in system.webServer/handlers, find FastCGI module
The FastCGI module (iisfcgi.dll) looks up handlers@scriptProcessor in fastCgi/applications
The FastCGI module spawns a new FastCGI process
The module then starts communicating with the process, according to the FastCGI protocol
The FastCGI process generates and returns a response
Request 2: HTTP GET /hello.php
(same as above, except request 1's process is re-used)

As you can see there are many places where the FastCGI module expects to have a FastCGI process to communicate with. If the FastCGI process disappears at any of these steps, the "The FastCGI process exited unexpectedly" error occurs. If this happens frequently Rapid Failure Protection may be enabled.

Here are some common causes for this error:

The FastCGI process calls some sort of ExitProcess API, e.g. the C exit() function
An unhandled exception occurs, e.g. Access Violation

ExitProcess:

If the FastCGI is a script interpreter, the scripting language may support some sort of ExitProcess function and the script may call it. (though PHP's exit() function does not seem to exit the process)
FastCGI processes often voluntarily exit after performing a certain number of requests. (e.g. PHP 5.2.1 does so at about 250 and can be configured) If the FastCGI module is expecting (fastCgi/application@instanceMaxRequests) the FastCGI process to perform more requests then this can also be a source of this error. This error can only happen in the time between when the next request arrives and the module detects the process' exit. This happens most often on busy servers, where requests are queuing for a FastCGI process.

Access Violations are more difficult to debug. The first step is to create a simple repro, here are repros sorted from simplest to most challenging:

Command line, without FastCGI. (e.g. \php\php.exe \inetpub\wwwroot\hello.php)
Command line, with a web environment. (e.g. Ruby's Webrick, or my fake FastCGI server)
Single HTTP request. (e.g. recycle AppPool, GET /hello.php)
Only under load. (e.g. Only when wcat is hitting the site)
Randomly. (e.g. Only in production)

Once you have the simplest script with the simplest repro, you need to debug it. Download Windbg or the IIS debug toolkit. The rest of this post discusses Windbg debugging, though the debug toolkit is often simpler and easier.

Attach the debugger:

For command-line failures, prefix the debugger onto the command. (e.g. c:\debuggers\ntsd -g -G \php\php.exe \inetpub\wwwroot\hello.php)

For AppPool debugging, you'll need to attach after starting the AppPool, e.g.

        D:\>net start w3svc
        The World Wide Web Publishing Service service is starting.
        The World Wide Web Publishing Service service was started successfully.


        D:\>start http://localhost/dne

        D:\>\Windows\system32\inetsrv\appcmd list wps
        WP "4012" (applicationPool:DefaultAppPool)

        D:\>c:\debuggers\ntsd -o -g -G -p 4012

Reproduce the Access Violation, you should see something like this in the debugger:

Executable search path is:
ModLoad: 00370000 00374000   av.exe
ModLoad: 77380000 774a6000   ntdll.dll
ModLoad: 76a80000 76b5b000   D:\Windows\system32\kernel32.dll
ModLoad: 75eb0000 75f5a000   D:\Windows\system32\msvcrt.dll
(ce4.d30): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00372374 edx=00000000 esi=00000001 edi=00372374
eip=00371190 esp=0014fe24 ebp=0014fe28 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
*** ERROR: Module load completed but symbols could not be loaded for av.exe
av+0x1190:
00371190 c700adbaadba    mov     dword ptr [eax],0BAADBAADh ds:0023:00000000=???
?????
0:000>

If you don't see an access violation occur in the debugger, then you don't have a reliable repro. Go back to creating a small simple repro. (very rarely certain AVs only happen when NOT under a debugger).

Setup symbols:

0:000> .sympath SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\localsymbols*http://msdl.microsoft.com/download/sy
mbols
0:000> .lines
Line number information will be loaded
0:000> k
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdl
l.dll -
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0014fe28 00371312 av+0x1190
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for D:\W
indows\system32\kernel32.dll -
0014fe6c 76ac1d02 av+0x1312
0014fe78 773b85db kernel32!BaseThreadInitThunk+0x12
0014feb8 773b85ae ntdll!RtlInitializeExceptionChain+0x64
0014fed0 00000000 ntdll!RtlInitializeExceptionChain+0x37
0:000> lml
start    end        module name
00370000 00374000   av         (no symbols)
7c800000 7c8f5000   kernel32   (pdb symbols)          c:\symbols\kernel32.pdb\CE
65FAF896A046629C9EC86F626344302\kernel32.pdb
7c900000 7c9b0000   ntdll      (pdb symbols)          c:\symbols\ntdll.pdb\36515
FB5D04345E491F672FA2E2878C02\ntdll.pdb

If symbols are working, then, after "k" (stack back trace), "lml" (list loaded modules) will not show "no symbols" or "export symbols". The Microsoft symbol server only gets Microsoft symbols. You'll also need symbols for the application, e.g. If you're debugging PHP use the PHP Snapshot php bits, and then use the "Debug pack" symbols (.sympath+ \path\to\debugpack; .reload). If you're using Ruby, you'll probably need to build from source and then ".sympath+ " to wherever ruby puts the .pdb files.

Share out the stack backtrace (the "k" command's output) with whoever you think may own it.

Other useful tricks:

Take a memory dump. (".dump /ma \av.dmp") and then share out the av.dmp file and any symbols you did not get from the Microsoft symbol server.
The Windows heap has a built-in memory-checking feature called pageheap. It makes debugging certain memory-usage errors extremely easy. On the downside, it slows the process down substantially and uses massive amounts of memory, so use caution before enabling it and remember to turn it off before perf testing. Here is a sample usage:
1. ensure no ruby.exe processes exist
2. gflags /p /enable ruby.exe /full
3. start ruby.exe, cause av, debug
4. gflags /p /disable ruby.exe
5. gflags /p (should say "no application has page heap enabled")

Happy Debugging!

FastCGI Rapid Failure Protection

rickjames — Fri, 12 Oct 2007 17:56:00 GMT

FastCGI Rapid Failure Protection

There are a lot of similarities between FastCGI's Rapid Failure Protection feature and w3svc/WAS', read here for more information.

FastCGIs performance (vs CGI) is derived from amortizing process creation and startup costs across multiple requests. When a process exits unexpectedly during a FastCGI request, FastCGI needs to spawn another one (expensive). When a process AVs (Access Violation), Windows Error Reporting generates a summary log of the issue (expensive).

It is not uncommon for a request that fails once to fail every time. If every time a request is made the expensive process creation, process startup and Windows Error Reporting must run, then the failing request is consuming relatively massive amounts of machine resources. (vs a successful request). Meaning most of the machine's resources are going towards doing something that will have no value.

FastCGI remembers whenever a process exits unexpectedly or misbehaves. If too many of these events occur in too short a period Rapid Failure Protection is enabled. When enabled, all requests to the fastCgi/application will result in HTTP 500s, with the error message: "The FastCGI process has failed frequently recently. Try the request again in a while". After a short period (less than 1 minute), Rapid Failure Protection will be disabled and process creation will start again. If failures start to happen again, then Rapid Failure Protection kicks in again.

IIS 7 C++ Module API Sample: Changing Handlers

rickjames — Fri, 12 Oct 2007 16:14:00 GMT

IIS 7 C++ Module API Sample: Changing Handlers

Introduction

Today's modules looks at how you can programmatically change handlers. RQ_EXECUTE_REQUEST_HANDLER is by far the most common notification used in the IIS 7 pipline. This makes sense because it is where the response is generated. We know how many different response generation techonologies there are out there. The RQ_EXECUTE_REQUEST_HANDLER notification is only delivered to the modules configured in system.webServer/handlers for the request. This is unlike all other request (RQ_*) notifications, where all modules in system.webServer/modules, that have registered for a notification receive it. The system.webServer/handlers configuration syntax is pretty flexible, but obviously cannot do everything for everyone. This post assumes you've already got the hello world module working, so it jumps straight into API discussion.

Pipeline

Here is the first portion of request pipeline. (from the top of httpserv.h) You can see there's an entire notification dedicated to handler selection. You can also see that by this point in the pipeline the request is already authenticated and authorized.

#define RQ_BEGIN_REQUEST               0x00000001
#define RQ_AUTHENTICATE_REQUEST        0x00000002
#define RQ_AUTHORIZE_REQUEST           0x00000004
#define RQ_RESOLVE_REQUEST_CACHE       0x00000008
#define RQ_MAP_REQUEST_HANDLER         0x00000010
#define RQ_ACQUIRE_REQUEST_STATE       0x00000020
#define RQ_PRE_EXECUTE_REQUEST_HANDLER 0x00000040 
#define RQ_EXECUTE_REQUEST_HANDLER     0x00000080
...

Deciding When to Change Handlers

The whole reason we're writing this module is because the built-in system.webServer/handlers configuration does not meet our needs. So we need our own logic. In this case we're going to target some special logic that Ruby on Rails seems to like: deliver that which can be delivered and render the rest unto Rails. First we check if we have a IScriptMapInfo already associated with the request. If we do it means that system.webServer/handlers could find a handler. If no handler could be found it means we should deliver it to Rails. If we can find a handler then we need some additional checks: first we use IHttpContext::GetFileInfo to check if this request maps to a file on the file system. Finally, some handlers do not need file system backing, so we compare IScriptMapInfo::GetResourceType to 3. (3 is from the system.webServer/handlers definition in %WinDir%\system32\inetsrv\config\schema\iis_schema.xml)

MODULE::OnMapRequestHandler(
    IHttpContext*           pContext,
    IMapHandlerProvider*    pProvider
)
{
    ...

    IScriptMapInfo* pScriptMap = pContext->GetScriptMap( );

    ...

    if( NULL != pScriptMap )
    {
        if(
            NULL != pContext->GetFileInfo( ) ||
            3 == pScriptMap->GetResourceType( )
        )
        {
            //
            // if we have a script map AND
            //      - a file info
            //      - or resourceType=Unspecified (3)
            // then no need to change handlers
            //
            goto Finished;
        }
    }

Choosing the New Handler

We now know that we want to deliver the request to Rails. One solution at this point would be to implement IScriptMapInfo and set the IScriptMapInfo::GetModules to be our Rails handler module. The problem with this solution is that there is more than one way to run Rails on IIS, so we don't know which module should handle Rails. So we need to expose some configuration to the web server administrator. At this point we could get into schema extensibility, but there's already a perfectly good configuration section that does almost exactly what we want: system.webServer/handlers! :-). So we tweak the URL to make it look like something system.webServer/handlers would understand (replace the stuff after the last slash with index.rb) and then we ask IIS to do the work for us:

    //
    // Get handler for pszScriptName/APPEND_PATH
    //
    hr = pContext->MapHandler(
        pSite->GetSiteId( ),
        pSite->GetSiteName( ),
        pszFullAppPath,
        pRequest->GetHttpMethod( ),
        &pScriptMap,
        FALSE
    );
    if( FAILED( hr ) )
    {
        goto Finished;
    }

    //
    // Now make that the handler for this request
    //
    pProvider->SetScriptMap( pScriptMap );

Deployment

Since this is a C++ module it needs to be in system.webServer/globalModules. Since this module uses RQ_* notifications is need to be in the application module list (system.webServer/modules). This later requirement means you now have a method for turning this custom handler selection on/off, cause system.webServer/modules is configurable at the application level. (e.g. only add the module in web.configs where you want Rails-style handler mapping). Finally, cause we're using the system.webServer/handlers configuration, we should add an entry for *.rb, mine looks like:

    <location path="" overrideMode="Allow">
        <system.webServer>
            <handlers accessPolicy="Read, Script">
                ...
                <add 
                    name="rails (currently broken)" 
                    path="*.rb" 
                    verb="GET,HEAD,POST" 
                    modules="FastCgiModule" 
                    scriptProcessor="c:\ruby\ruby.exe" 
                    resourceType="Unspecified" 
                />
                ...

Expected Behaviour

http://localhost/a.rb should get an HTTP 500 with detailed error of "<handler> scriptProcessor could not be found in <fastCGI> application configuration." (I still haven't got Rails working as a FastCGI on IIS 7, I'll blog about it when I do)
http://localhost/app1/recipe/new should get the same HTTP 500 if our module is running and a regular HTTP 404 if not

"Failed Request Tracing" log should have something like this:

NOTIFY_MODULE_START 
    ModuleName="RubynatorModule"
    Notification="MAP_REQUEST_HANDLER"
HANDLER_CHANGED 
    OldHandlerName="StaticFile"
    NewHandlerName="rails (currently broken)"
    NewHandlerModules="FastCgiModule"
    NewHandlerScriptProcessor="c:\ruby\ruby.exe"
    NewHandlerType=""
NOTIFY_MODULE_END 
    ModuleName="RubynatorModule"
    Notification="MAP_REQUEST_HANDLER"

Getting Ruby on Rails Working

This is beyond the scope of this article, checkout this excellent wiki entry.

IIS 7 C++ Module API Sample: Consuming Trace Events

rickjames — Wed, 10 Oct 2007 20:52:00 GMT

Introduction

The attached sample IIS 7 module converts all tracing events into OutputDebugString calls. This is not something you'd want to do on a production box, because OutputDebugString can slow machines substantially. It is however very useful when you're performing functional debugging. This post assumes you've already got the hello world module working, so it jumps straight into API discussion. (There are many types of tracing from Microsoft, here is a diagram which attempts to show the relationships)

Registration

The module registers to receive trace events. There are many trace events available, so which events you'd like to receive is configured is HTTP_TRACE_CONFIGURATION. The hierarchy is identical to ETW's (provider, area, verbosity). When you configure these settings in the UI for "Failed Request Tracing", iisfreb.dll is converting that configuration into a couple of HTTP_TRACE_CONFIGURATION structures. Providers are identified by a GUID. For simplicity/convenience a special GUID, called GUID_IIS_ALL_TRACE_PROVIDERS is available. It is the equivalent to asking for all registerer trace providers. (Creating a custom provider is not covered in this post) For consistency's sake, the module also has to register for the GL_TRACE_EVENT notification.

    HTTP_TRACE_CONFIGURATION TraceConfiguration = {0}; 
    TraceConfiguration.pProviderGuid    = &GUID_IIS_ALL_TRACE_PROVIDERS;
    TraceConfiguration.dwAreas          = 0xFFFF;
    TraceConfiguration.dwVerbosity      = 5;
    TraceConfiguration.fProviderEnabled = TRUE;

    ...

    hr = pModuleInfo->SetGlobalNotifications( pGlobalModule, GL_TRACE_EVENT );

    ...

    hr = pGlobalInfo->GetTraceContext( )->
        SetTraceConfiguration( g_pModuleContext, &TraceConfiguration, 1 );

Consumption

Since the module registered for GL_TRACE_EVENT, it must implement GLOBAL_MODULE::OnGlobalTraceEvent. This function is called every time an event is raised. Now it's simply a matter of extracting interesting information from the event and OutputDebugString'ing it:

    hr = pProvider->GetTraceEvent( &pEvent );

    ...

    cItems = pEvent->cEventItems;

    hr = StringCchPrintf(
        pszBuffer,
        sizeof( pszBuffer ) / sizeof( pszBuffer[0] ),
        L"Event: %s (%s,%s,%s,%s)\n",
        pEvent->pszEventName,
        ...

    OutputDebugString( pszBuffer );

Since this module only subscribes to global events, it only needs to be in the <globalModules> list. Once working you should see output like this in your debugger/dbmon:

Event: GENERAL_REQUEST_START (,,DefaultAppPool,)
Event: PRE_BEGIN_REQUEST_START (,FailedRequestsTracingModule,,)
Event: PRE_BEGIN_REQUEST_END (,FailedRequestsTracingModule,,)
Event: PRE_BEGIN_REQUEST_START (,RequestMonitorModule,,)
Event: PRE_BEGIN_REQUEST_END (,RequestMonitorModule,,)
Event: PRE_BEGIN_REQUEST_START (,IsapiFilterModule,,)
Event: FILTER_START (,D:\Windows\Microsoft.NET\Framework\v2.0.
50727\aspnet_filter.dll,,)
Event: FILTER_PREPROC_HEADERS_START (,,,)
Event: GENERAL_SET_REQUEST_HEADER (,,,)
Event: FILTER_SET_REQ_HEADER (,,,)
Event: FILTER_PREPROC_HEADERS_END (,,,)
Event: FILTER_END (,,,)
Event: PRE_BEGIN_REQUEST_END (,IsapiFilterModule,,)
Event: GENERAL_REQUEST_HEADERS (,,,)
Event: URL_CACHE_ACCESS_START (,/d,,)
Event: URL_CACHE_ACCESS_END (,,,)
Event: HANDLER_PRECONDITION_NOT_MATCH (,AXD-ISAPI-2.0,class
icMode,runtimeVersion

Installing PHP 5.2.4 on Windows Server 2008 RC0 in Pictures

rickjames — Fri, 05 Oct 2007 01:40:00 GMT

Windows Server 2008 RC0 is now available for beta testing. Here are some screenshots of setting up PHP 5.2.4:

Update: 11-Oct: changed image layout, tweaked text

Open Server Manager, Install IIS, including CGI (which include FastCGI)
Download and extract PHP to c:\php, Start the UI (WindowsKey+R - inetmgr)

Create a simple php script c:\inetpub\wwwroot\hello.php:

<?php phpinfo(); ?>

Let IIS know the you want *.php to run as a FastCGI using c:\php\php-cgi.exe
Browse away!

Server 2008 Beta 3 experience (a video)

IIS 7 Talks: Slides

rickjames — Tue, 29 May 2007 13:00:00 GMT

Will and I had the pleasure of presenting IIS 7 to audiences in 6 countries in the last 2 weeks. Sorry to people who found out about the presentations too late to attend. I've attached a copy of the slides we used. You may also want to see the shared hosting on IIS 7 document.

IIS 7 Talks: Zagreb, Athens, Brussels and Belgrade

rickjames — Thu, 10 May 2007 12:53:00 GMT

As previously mentioned, in the next two weeks, Will and I will be doing a bunch of IIS 7 day-long talks. (Brett and Isaac will visit other countries, see here for the full list) Final locations and dates:

14 May: Reykjavik

16 May: Zagreb

18 May: Athens

21 May: Belgium

23 May: London

25 May: Belgrade (message me for registration information, I don't have a link)

Looking forward to seeing you there!

IIS 7 Talks: Reykjavik and London

rickjames — Sun, 06 May 2007 11:53:00 GMT

Will and I will be presenting one day talks, aimed at IT professionals, about IIS 7. Schedule:

14 May: Reykjavik (details and registration)
23 May: London (details and registration)

We're still finalizing details, but it looks like we'll also be talking in Zagreb, Athens, Brussels and Belgrade. Topics:

Overview
New UI
Shared Configuration, Remote Administration and Tools
Security
Troubleshooting

Looking forward to seeing iis.net people there!

FastCGI TP2 - Unofficial Update 70419

rickjames — Thu, 19 Apr 2007 16:56:00 GMT

FastCGI tech preview 2 went out a long time ago. Since then there has been tons of excellent feedback in the FastCGI forums on http://forums.iis.net. Thank you!

Unfortunately it's going to be a while before there's another official tech preview / beta. In the mean time, I've attached bits that contain fixes for all issues reported to date. I must warn you: The attached update bits have not been as thoroughly tested as TP2, so you mileage may vary. Please report any issues you encounter to forums.iis.net and highlight that you're using unofficial update 70419.

In other good FastCGI news: FastCGI will be in Longhorn Server Beta 3! (not released yet)

IIS 7 Hello World Module Walkthrough

rickjames — Tue, 27 Feb 2007 07:53:00 GMT

The other day I found out that the Vista SDK includes a compiler. I was very excited to find this out, cause now creating a "Hello World" IIS 7 C++ module only requires one huge install (and two little ones).

Build:

Install the Vista SDK
Unzip attached helloworld.zip to \temp\hello
cd "\Program Files\Microsoft SDKs\Windows\v6.0\Bin"
setenv.cmd /debug /x86 /vista
cd \temp\hello
build.bat

Deploy:

cd %windir%\system32\inetsrv
appcmd add backup hellobackup
appcmd install module /name:Helloworld /image:\temp\hello\hello_world.dll
appcmd set config -section:handlers "-+[name='HelloHandler',path='*.hello',verb='*',modules='Helloworld']"

Test:

Install wfetch
Set the path field to: /a.hello
Expected: Hello World

Debug:

Install the debugger to c:\debuggers (checkout c:\debuggers\debugger.chm index tab for more details on the commands below)
cmd: net stop was /y
cmd: cd %windir%\system32\inetsrv
cmd: c:\debuggers\windbg -2 -g -G w3wp.exe /debug
debugger: Ctrl-Break
debugger: .sympath SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
debugger: bm hello_world!*execute*
debugger: g
wfetch: F5

May the force be with you :-).

Fake FastCGI Web Server

rickjames — Sun, 04 Feb 2007 21:18:00 GMT

When developing a new FastCGI library, the web server can get in the way. The attached program wraps a FastCGI executable in a minimal FastCGI environment. It should be enough to get "hello world" working. It only uses named pipes. It doesn't exercise all FastCGI protocol features. Sample PHP 5 run:

C:\>fakefcgi.exe c:\Inetpub\wwwroot\hello.php c:\php\php-cgi.exe

Fake FastCGI web server
FCGI_PARAMS sent
FCGI_STDIN sent
Launching receive loop
FCGI_STDOUT: X-Powered-By: PHP/5.2.1RC2-dev
Content-type: text/html

Hello World 2 from IIS

FCGI_END_REQUEST received
killing app
FastCGI process exited with 0

C:\>type c:\Inetpub\wwwroot\hello.php <?php echo 'Hello World 2 from IIS'; ?>
Sample Perl run:

C:\>fakefcgi.exe c:\Inetpub\wwwroot\hello.plfcgi "C:\Perl\bin\perl.exe c:\inetpub\wwwroot\hello.plfcgi"

Fake FastCGI web server
FCGI_PARAMS sent
FCGI_STDIN sent
Launching receive loop
FCGI_STDOUT: hello world
FCGI_STDOUT: (null)
FCGI_END_REQUEST received
killing app
FastCGI process exited with 0

C:\>type c:\Inetpub\wwwroot\hello.plfcgi
use CGI::Fast qw(:standard);
$COUNTER = 0;
while (new CGI::Fast) {
    print "hello world";
}

As you can see, this is only really useful for the initial development of a Windows FastCGI Named Pipe library. That being said, once in a while it's useful to see a script running from the command line inside FastCGI.

IIS 7 FastCGI Module

rickjames — Tue, 31 Oct 2006 17:47:00 GMT

The IIS FastCGI preview is ready! I spent the last month developing the IIS 7 FastCGI module. Wade has adapted the module to work as an ISAPI on IIS 6 (and unofficially on IIS 5). Marchel and Mukhtar (and recently Cip) have been testing until late in the evenings for the last few weeks. Bill and Mike have been managing the project. It was really exciting going from nothing to something in 1 month. Normally we take product development at a slower pace.

Thank you to these excellent PHP developers: Dmitry, Wez, Andi and Stanislav. I'm guessing most of them are currently at the San Jose Zend/PHP Conference

I don't know what throughput numbers will be officially recorded, but unofficial ones I've tested (helloworld.php, Longhorn Server, pre-release PHP bits) are running 25x (twenty-five TIMES) faster than running PHP as a CGI. So this is a real win for people who cannot run PHP as an ISAPI. (Some PHP extensions are not thread safe and therefore couldn't be run safely as ISAPIs. I don't know which ones, just have nasty stories from Andreas in CSS)

Technology Preview 1 is be available on www.iis.net. So far I've only tested it with PHP and the libfcgi SDK sample echo.exe. I'd love us to try out some other technologies, so if you have any suggestions please comment on the FastCGI forums. If you find any FastCGI apps we're incompatible with, please bring it to our attention and we'll get them working!

Overview of the current design (which could change substantially before release):

Configuration applies at the worker process level
Each worker process can be configured to run many FastCGI process pools
Each process pool can be configured independently
Processes are spawned on demand up to the maximum (there is no MinServers setting)
If there are more requests than processes, requests are queued up to request limits
If a FastCGI process has been idle for more than 5 minutes we retire it

IIS 7 configuration settings (per process pool):

fullPath: path to application for this pool (e.g. d:\php\php-cgi.exe, NOTE: must match handlers section)
maxInstances: maximum number of processes to create in this pool
instanceTimeout: maximum duration a request can last
instanceMaxRequests: process will be retired after exceeding this number of requests
protocol: use named pipes or tcp. The tech preview currently only supports named pipes, but TCP should be simple to add.
queueLength: maximum number of requests to queue (when this is exceeded the module will start 500'ing)
flushNamedPipe: Flush the named pipe at the end of each request. This is to workaround, what seems to be a bug in libfcgi: if two FastCGI requests arrive in a single ReadFile call, libfcgi closes the pipe. (If anyone wants to tackle this problem, I'd be happy to provide a repro)

Links: