LiveChat 
Support 
Apache Web Server Performance: A Complete Tuning Guide for Speed and Concurrency
Apache HTTP Server remains one of the most widely deployed web servers in the world, powering everything from small WordPress blogs to large enterprise applications. Yet many Apache installations run on default settings that leave significant performance on the table. With the right configuration, Apache can serve traffic quickly and handle high concurrency without consuming excessive memory or CPU.
This guide walks through the most impactful Apache web server performance optimizations: selecting the correct Multi-Processing Module (MPM), enabling caching and compression, tuning connection settings, offloading PHP to PHP-FPM, and adopting modern protocols like HTTP/2.
Key Takeaways
• The biggest single performance win is usually switching from prefork + mod_php to the event MPM + PHP-FPM.
• The event MPM handles high concurrency far better than prefork because it does not tie up a process per connection.
• Caching (`mod_cache`, `mod_expires`) and compression (`mod_deflate`, Brotli) reduce both load and bandwidth.
• Setting `AllowOverride None` and disabling unused modules removes hidden overhead.
• For some workloads, LiteSpeed is a faster drop-in alternative to Apache.
Why does the default Apache configuration run slowly?
Out of the box, many Apache builds ship with the prefork MPM and mod_php, a combination chosen for compatibility rather than speed. Prefork spawns a separate process for every connection, and each process loads a full copy of the PHP interpreter. Under concurrent load, memory usage balloons and the server quickly runs out of available workers.
Default configurations also tend to enable modules that most sites never use, allow `.htaccess` overrides on every directory, and ship with conservative caching and compression settings. Each of these adds latency or wastes resources. The good news is that every one of them is tunable.
Which Apache MPM should you choose?
The Multi-Processing Module controls how Apache handles concurrent connections, and it is the foundation of Apache performance. There are three main options.
| MPM | Concurrency model | Memory footprint | Thread-safe PHP needed? | Best for |
|---|---|---|---|---|
| prefork | One process per connection, no threads | High | No (works with mod_php) | Legacy apps requiring non-thread-safe modules |
| worker | Hybrid: multiple processes, each with multiple threads | Medium | Yes | General-purpose, moderate concurrency |
| event | Like worker, but dedicates a separate thread to manage idle/KeepAlive connections | Low | Yes | High concurrency, modern PHP-FPM stacks |
The event MPM is the best choice for most modern deployments. By offloading idle and KeepAlive connection management to a dedicated listener thread, it frees worker threads to do real work, which dramatically improves how many simultaneous connections a server can sustain. Prefork should be reserved for the increasingly rare cases where a non-thread-safe module is genuinely required.
The reason event MPM and prefork perform so differently in practice comes down to what happens to PHP. With prefork, you are almost always running mod_php, which embeds the PHP interpreter inside every Apache process. That means even a request for a static image holds a fully loaded PHP-capable process hostage. Switching to the event MPM paired with PHP-FPM decouples PHP execution from connection handling entirely: Apache becomes a lean reverse proxy that hands PHP requests to a separate, independently tuned process pool. In real-world tuning work, this single change, moving from prefork + mod_php to event + PHP-FPM, is frequently the largest performance improvement available, often outweighing every other tweak combined.
How do you switch from mod_php to PHP-FPM?
PHP-FPM (FastCGI Process Manager) runs PHP as its own service rather than inside Apache. This separation delivers several benefits:
- Apache can use the event or worker MPM instead of being locked to prefork.
- PHP worker counts, memory limits, and process management are tuned independently of web server workers.
- Static assets are served without ever touching the PHP interpreter.
- A PHP restart no longer requires restarting the entire web server.
On most systems you connect Apache to PHP-FPM with `mod_proxy_fcgi` and a handler directive that routes `.php` requests to the FPM socket. After enabling the event MPM and disabling mod_php, PHP requests flow to the FPM pool, which you size using `pm`, `pm.max_children`, and related directives based on available RAM.
How should you tune connection limits and KeepAlive?
Connection tuning ensures Apache neither starves under load nor wastes memory on idle clients.
- `MaxRequestWorkers` sets the maximum number of simultaneous requests Apache will serve. Set it too low and visitors queue; set it too high and the server can exhaust memory and start swapping. Calculate it from available RAM divided by the average memory used per worker.
- `KeepAlive On` lets clients reuse a single connection for multiple requests, avoiding repeated TCP and TLS handshakes. This is a clear win, especially with HTTP/2.
- `KeepAliveTimeout` should be kept short (a few seconds). A long timeout holds connections open needlessly, which matters far less on the event MPM but still wastes resources.
- `MaxConnectionsPerChild` can be set to periodically recycle worker processes, mitigating slow memory leaks in third-party modules.
The interplay between these directives and your chosen MPM is what determines real-world concurrency. Always load-test after changes rather than guessing.
How do caching and compression speed up Apache?
Serving fewer bytes, and serving repeat content from cache, reduces both response time and server load.
Caching with `mod_cache` (and `mod_cache_disk`) stores generated responses so Apache can return them without regenerating the content. Pair this with `mod_expires` to set far-future `Expires` and `Cache-Control` headers on static assets like images, CSS, and JavaScript, so browsers and CDNs avoid re-requesting unchanged files.
Compression shrinks text-based responses before they travel over the network:
- `mod_deflate` provides gzip compression, which is broadly supported and easy to enable for HTML, CSS, JavaScript, JSON, and SVG.
- Brotli (`mod_brotli`) typically compresses text more efficiently than gzip and is supported by all modern browsers. Enabling Brotli alongside gzip lets the server pick the best option per client.
Avoid compressing already-compressed formats such as JPEG, PNG, and video, since re-compressing them wastes CPU for no benefit.
What overhead comes from .htaccess and unused modules?
Two often-overlooked sources of overhead are `.htaccess` processing and unnecessary modules.
When `AllowOverride` is set to anything other than `None`, Apache checks every directory along a request’s path for a `.htaccess` file on every single request. This filesystem lookup adds measurable latency at scale. Whenever you control the main server configuration, set `AllowOverride None` and move those rules into the main `
Similarly, every loaded module consumes memory and may add processing per request. Audit your loaded modules and disable anything you do not use, such as unused authentication, language, or status modules. A leaner Apache starts faster and uses less RAM per worker.
How does HTTP/2 improve performance?
HTTP/2 introduces multiplexing, header compression, and stream prioritization, allowing many requests to share a single connection without the head-of-line blocking of HTTP/1.1. Enabling the `mod_http2` module (over HTTPS) reduces latency for asset-heavy pages and pairs naturally with KeepAlive and the event MPM.
Because HTTP/2 multiplexes efficiently over one connection, the old HTTP/1.1 practice of sharding assets across multiple domains becomes counterproductive. Serve assets from a single origin and let HTTP/2 do the work.
DarazHost: optimized servers and full root control
Tuning Apache is far easier on infrastructure built for performance. DarazHost hosting runs on optimized web servers, LiteSpeed and finely tuned Apache, with server-level caching enabled for speed out of the box. For teams that want to manage everything themselves, our VPS and dedicated plans provide full root access, so you can choose your own MPM, deploy PHP-FPM, enable HTTP/2, and tune `MaxRequestWorkers` exactly to your workload.
Every plan is backed by fast SSD storage, an integrated CDN to serve assets closer to your visitors, and 24/7 support from engineers who understand web server performance. Whether you want a managed, pre-optimized stack or the freedom to tune Apache to the last directive, DarazHost gives you the foundation to do it.
Is LiteSpeed a faster alternative to Apache?
For some workloads, LiteSpeed is worth considering as a drop-in replacement. It reads Apache configuration and `.htaccess` files directly, so migration is usually straightforward, yet it uses an event-driven architecture and built-in caching (such as LSCache) that can outperform a stock Apache setup, particularly for high-traffic PHP applications like WordPress.
That said, a well-tuned Apache running the event MPM with PHP-FPM, HTTP/2, and caching closes much of the gap. The right choice depends on your traffic patterns, application, and how much control you need over the configuration.
Frequently asked questions
Which Apache MPM is best for high concurrency? The event MPM is best for high concurrency. It dedicates a separate thread to managing idle and KeepAlive connections, so worker threads stay free to process active requests. This lets a single server handle far more simultaneous connections than prefork.
Is PHP-FPM faster than mod_php? In most modern setups, yes. PHP-FPM lets Apache run the efficient event MPM and serve static files without loading PHP, while PHP runs in an independently tuned process pool. Switching from prefork plus mod_php to event plus PHP-FPM is often the single biggest Apache performance improvement.
Should I enable both gzip and Brotli? Enabling both is a good strategy. Brotli generally compresses text more efficiently, while gzip (`mod_deflate`) ensures compatibility. With both enabled, Apache selects the best method each client supports.
Why does AllowOverride None improve performance? With `AllowOverride None`, Apache stops searching every directory for `.htaccess` files on each request, eliminating repeated filesystem lookups. Moving those rules into the main configuration means they are parsed once at startup instead of on every request.
Does HTTP/2 require HTTPS? In practice, yes. All major browsers only support HTTP/2 over TLS, so you need a valid certificate and HTTPS enabled to benefit from HTTP/2 multiplexing and header compression.
