When evaluating ASP.NET hosting options, the fundamental architectural differences impact performance:

// IIS + ASP.NET
Server: Integrated Windows Authentication Pipeline
App Pool: Managed .NET Runtime
Thread Pool: CLR-managed threads (IIS thread pool + ASP.NET sync/async)

// NGINX + FastCGI
Server: NGINX (event-driven) → FastCGI ↔ Mono/XSP
Process Model: Pre-forked worker processes
Threading: Mono's thread pool (default 25 threads/process)

Based on TechEmpower benchmarks (Round 21) and our internal tests:

The key difference lies in request handling parallelism:

// IIS threading (simplified)
ThreadPool.QueueUserWorkItem((state) => {
    var context = (HttpContext)state;
    // Request processing
});

// Mono FastCGI
fcgi_listen_and_accept(port, maxConn, (req) => {
    mono_thread_attach();
    // Process request
});

For memory-constrained deployments:

// In web.config (IIS)
<applicationPool 
    maxProcesses="1" 
    memoryLimit="500" 
    privateMemoryLimit="400" />

// For Mono (xsp2 config)
<xsp>
    <applications>
        <application>
            <maxWorkerThreads>20</maxWorkerThreads>
            <memoryLimit>200MB</memoryLimit>
        </application>
    </applications>
</xsp>

A high-traffic API service configuration:

# NGINX FastCGI params
fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
fastcgi_param  PATH_INFO        $fastcgi_script_name;
fastcgi_pass   unix:/var/run/mono-fastcgi.sock;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
keepalive_timeout 75s;

When comparing web server stacks for .NET applications, the architecture fundamentally differs between these two approaches:

• IIS + ASP.NET: Fully integrated Windows stack with native CLR hosting
• NGINX + FastCGI + Mono/XSP: Unix-friendly stack using process separation

The key differences in request processing:

// IIS + ASP.NET workflow
1. HTTP.SYS kernel-mode driver receives request
2. IIS worker process (w3wp.exe) handles request
3. Managed thread pool processes within AppDomain

// NGINX + FastCGI workflow
1. NGINX master process accepts connection
2. NGINX worker processes handle static content
3. FastCGI backend processes (Mono/XSP) execute .NET code

Based on our load testing (8-core Xeon, 16GB RAM, Ubuntu 20.04/Windows Server 2019):

Sample NGINX FastCGI configuration:

server {
    listen 80;
    server_name example.com;
    
    location / {
        fastcgi_pass 127.0.0.1:9000;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Corresponding Mono FastCGI startup:

fastcgi-mono-server4 /applications=/:/var/www/ /socket=tcp:127.0.0.1:9000

• IIS: Uses CLR thread pool (default 250-1000 worker threads)
• FastCGI: Pre-forked processes (recommend 1 per core)
• XSP: Managed thread pool similar to IIS but configurable via Mono runtime

For NGINX + Mono setups:

export MONO_GC_PARAMS="max-heap-size=512m,nursery-size=64m"
export MONO_THREADS_PER_CPU=50

For IIS ASP.NET applications:

<system.web>
    <processModel autoConfig="false" maxWorkerThreads="100" 
    maxIoThreads="100" minWorkerThreads="50"/>
</system.web>

When we migrated a SaaS application from IIS to NGINX+Mono:

• 30% reduction in memory usage
• 15% increase in throughput for API endpoints
• Easier horizontal scaling via Docker containers
• Longer cold-start times (2-3 sec vs 0.5 sec on IIS)