> For the complete documentation index, see [llms.txt](https://docs.uxwizz.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uxwizz.com/installation/optimization-tips/apache.md).

# Apache

Tune Apache only after checking the cause of slow or failed requests. Database queries, disk pressure, PHP limits, and network latency can each limit UXWizz performance. These checks need server access.

## Increase max CCU

CCU means concurrent users. Apache limits concurrent requests through its active processing module, while PHP-FPM has its own worker limits when used.

### 1. Allocate more resources

Check the active module and worker memory use before changing `MaxRequestWorkers`. Do not copy a value such as 2048 onto a small server: too many workers can exhaust RAM and make the service fail.

For a prefork/mod\_php setup, estimate the worker budget from available RAM after reserving memory for the database and operating system. For an event/PHP-FPM setup, review both Apache and PHP-FPM limits.

See the [Apache MaxRequestWorkers reference](https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers). Back up the configuration, validate it before reloading, and compare error rates and memory use after the change.

On Ubuntu, identify the loaded module with `sudo apache2ctl -M`. For **prefork**, edit `/etc/apache2/mods-available/mpm_prefork.conf`. The original high-concurrency settings were:

```apache
ServerLimit 2048
MaxRequestWorkers 2048
```

Use those values only if measured worker memory and the server's reserved memory support that many processes. For example, 2,048 workers using 20 MB each can need about 40 GB for Apache alone. Choose a lower limit for a smaller memory budget. Event/worker MPM and PHP-FPM have different limits; the prefork example is not interchangeable with them.

Run `sudo apache2ctl configtest` after editing. Changes to `ServerLimit` require a full Apache stop/start during a maintenance window; a graceful reload does not change that limit. Recheck the effective module configuration and memory use under load.

### 2. Kill connections faster

Review keep-alive timeouts under your actual traffic. Turning `KeepAlive` off is not a general performance improvement: it creates more new connections and can increase latency.

Keep the working configuration until measurements support a change. If Apache is healthy but reports are slow, review [database performance](/installation/optimization-tips/mysql-mariadb.md) and data retention instead.

For a measured **prefork** bottleneck where idle keep-alive connections occupy workers, you can test the original setting in the site's Apache configuration:

```apache
KeepAlive Off
```

Back up the configuration, validate it, and reload Apache. Compare throughput, latency, CPU use, and connection counts under similar traffic. Restore `KeepAlive On` if the result is worse. A shorter `KeepAliveTimeout` is another option to measure before turning connection reuse off.