Server-Side Execution Models

← Back to Home

There are several distinct models for executing server-side code to generate dynamic web content. Each model has different trade-offs in terms of performance, portability, and complexity. Understanding these models helps you choose the right approach for your application.

1. Fork/Exec (CGI)

The traditional CGI (Common Gateway Interface) model. For each request, the web server forks a new process and executes the script. The script runs, produces output, and terminates.

Client request Apache (Web Server) fork+exec Script (new process) output + exit response
Performance Process creation overhead for every request
Portability Very high - works with any language
Isolation Complete - each request is separate process
State No built-in state; requires external storage
Examples on this site: Perl, Python, C, Ruby, Go (in CGI section), Node.js CGI-style

2. Server-Side Scripting (Embedded Interpreter)

The scripting interpreter runs inside the web server process as a module. Scripts are parsed and executed without forking new processes, eliminating the fork/exec overhead.

Client request Apache (Web Server) Embedded Interpreter (mod_php, mod_perl, etc.) parses & executes script response
Performance Good - no process creation overhead
Portability Medium - requires specific server module
Isolation Limited - scripts share server process
State Can share state within server process
Examples on this site: PHP (mod_php), SSI (mod_include)
Historical: Classic ASP, ColdFusion, JSP, ASP.NET

3. Embedded Native (Server Modules)

Custom code compiled directly into the web server as a native module. The code runs as part of the server process with full access to server internals. Maximum performance but requires recompilation for changes.

Client request Apache (Web Server) Native Module (C) compiled into server direct memory access response
Performance Highest - native code, no interpretation
Portability Low - server and platform specific
Isolation None - bugs can crash server
Difficulty High - requires C/systems programming
Examples on this site: Apache Modules (mod_hello, mod_env_demo, mod_form)
Other: IIS ISAPI extensions, nginx modules

4. Code as Server (Standalone Application Server)

The application runs its own HTTP server as a persistent process. A traditional web server (Apache, nginx) acts as a reverse proxy, forwarding requests to the application server. This is the dominant model for modern web applications.

Client request Apache (reverse proxy) proxy Application Server (Node, Flask, etc.) persistent process in-memory state response
Performance Good - persistent process, but proxy overhead and interpreted languages
Portability High - runs anywhere the language runs
State In-memory state, WebSockets, connections
Scalability Can run multiple instances behind load balancer
Examples on this site: Node.js/Express, Python/Flask, Perl/Mojolicious
Other: Ruby on Rails (Puma), Go (net/http), Java (Spring Boot), Rust (Actix)

Note: Performance varies significantly by language runtime. Node.js (V8) is faster than Python (Flask). Go and Rust approach native performance. The proxy layer adds latency compared to embedded approaches.

Model Comparison

Model Performance Portability Difficulty Best For
Fork/Exec (CGI) Low High Medium Simple scripts, infrequent requests
Server-Side Scripting Medium Medium Low Traditional web apps, CMS systems
Embedded Native Highest Low High Maximum performance, server extensions
Code as Server Medium-High* High Medium Modern web apps, APIs, microservices

*Code as Server performance varies by language: Go/Rust approach native speed, Node.js is fast, Python/Ruby are slower. Proxy layer adds latency vs embedded approaches.

← Back to Home