What the Apache HTTP Server is, how it fits in a web stack, key features, HTTP/S and configuration concepts, pros and cons, request flow, throughput tuning with MPMs, and core tuning directives.
Apache HTTP Server is a free and open-source web server that delivers web content over the internet.
Apache web application architecture
Apache is one component in a typical web application stack. Apache is the web server that accepts HTTP requests and serves assets and content. MySQL (or another database) stores information in a queryable form. PHP or another language works with Apache to generate dynamic content. Firewalls protect the application from external threats and limit internal exposure depending on placement. Load balancers spread traffic across web servers that terminate HTTP(S) (where Apache often runs) and application servers that run business logic. Database servers handle persistence, backups, and scaling strategies alongside your app tier.
Features of Apache HTTP Server
- Handling of static files
- Loadable dynamic modules
- Auto-indexing
- .htaccess (per-directory overrides when enabled)
- Compatible with IPv6
- Supports HTTP/2
- FTP-related integrations (often alongside other services)
- Gzip compression and decompression
- Bandwidth throttling
- Perl, PHP, Lua, and other language integrations via modules
- Load balancing (often with mod_proxy_balancer and peers)
- Session tracking
- URL rewriting (mod_rewrite)
- Geolocation based on IP address (via modules)
How Apache fits with HTTP/S
Apache mediates communication between clients and your origin using TCP/IP. It supports multiple protocols, but HTTP and HTTPS are the most common. HTTPS (HTTP over TLS) usually listens on port 443; plain HTTP often uses port 80—exact ports depend on your Listen directives and reverse proxies.
HTTP defines how messages are formatted and transmitted and how browsers and servers respond to requests. Apache’s behavior is driven by configuration files and modules: which ports to bind, which virtual hosts answer for which hostnames, and how to route requests.
With the Listen directive, Apache binds to address:port combinations and can host many sites on one machine—for example different names on ports 80, 443, or alternate ports for staging—each mapped through VirtualHost blocks.
Under the hood, TCP ensures reliable delivery: receivers acknowledge (ACK) successful segments; lost data can be retransmitted when negative acknowledgment or timeouts occur. HTTP layers request/response semantics on top of that transport.
Apache itself is software that runs on a machine (not the hardware “server” box). It accepts connections from browsers, maps URLs to files or handlers, and returns responses. It runs on many operating systems. When someone loads a page, the browser issues an HTTP request; Apache handles it—possibly invoking PHP or another module—and returns HTML, assets, or API payloads.
Apache is highly customizable under an open-source license. Administrators enable or disable modules for caching, security headers, authentication, rewrite rules, and more. Per-directory rules often live in .htaccess when AllowOverride permits—useful on shared hosts; on dedicated servers, prefer central configs when possible for clarity and performance.
Apache pros
- Open source and free, including for many commercial deployments
- Mature, widely deployed, and stable
- Regular security updates when you stay on supported versions
- Flexible module-based architecture
- Well-documented; approachable for teams getting started
- Cross-platform (Linux, Windows, and others)
- Strong static file serving; works with many languages (PHP, Python via WSGI, etc.)
- Ubiquitous in WordPress and classic LAMP stacks
- Large community and abundant tutorials
Apache cons
- Very high concurrency workloads may require careful tuning or complementary caching layers
- Rich configuration surface area—misconfiguration can introduce security or performance issues
Execution of a typical PHP page
Example: loading a PHP-powered site such as laravel.com illustrates how Apache and PHP cooperate.
- The user enters http://laravel.com in the browser and presses Enter.
- The browser sends an HTTP request across the network to the origin web server.
- Apache accepts the request and inspects the method, path, and Host header. If no file is named explicitly, it may look for a directory index such as index.php.
- Apache hands .php files to the PHP interpreter (for example via mod_php or PHP-FPM, depending on setup).
- PHP executes index.php (and includes): it may query databases, read files, or call external APIs.
- PHP returns generated output (HTML, headers) back to Apache.
- Apache sends the HTTP response to the client—the web response.
- The browser renders the document and loads subresources as separate requests.
Requests per second
Throughput depends on hardware, TLS, PHP worker model, caching, and workload. Some baseline configurations are described with limits on the order of 160 requests per second until you tune MPMs, PHP-FPM pools, and caching—treat any headline number as deployment-specific and validate with load tests.
Increasing concurrency: MPM choice
To serve more simultaneous connections efficiently, teams often switch from mpm_prefork (one process per connection, higher memory) to mpm_worker or mpm_event, which use threads and scale better for many keep-alive connections—always test after changing MPMs because PHP deployment models (mod_php vs PHP-FPM) interact with them.
Key tuning parameters (examples)
Directive names and defaults depend on Apache version and MPM. Common knobs include:
- ServerLimit — upper bound on configured processes (worker/event)
- StartServers — processes created at startup
- MinSpareThreads / MaxSpareThreads — idle worker threads to keep warm
- ThreadsPerChild — threads inside each child process
- MaxRequestWorkers — cap on concurrent requests (critical for capacity planning)
- MaxConnectionsPerChild — recycle workers after N requests to mitigate leaks
Validate changes with load testing and monitor CPU, memory, and latency. Pair Apache tuning with OPcache, PHP-FPM pools, database indexes, and CDN caching where appropriate.