Apache HTTP Server 2.4 provides clustered reverse proxy capabilities using the mod_proxy_balancer extension module. In a load-balanced setup, incoming web requests are routed across multiple backend workers (nodes or application servers). This explainer details how the byrequests scheduler calculates request distribution using worker quotas, how sticky sessions maintain state across backend nodes, and how the built-in management interface allows dynamic worker changes.
Apache Balancer Architecture and Available Schedulers
In Apache 2.4, load balancing logic is separated into mod_proxy_balancer and modular scheduler algorithms configured via the lbmethod parameter. According to the Apache mod_proxy_balancer documentation, four scheduler algorithms are available:
- Request Counting (
mod_lbmethod_byrequests): Enabled withlbmethod=byrequeststo balance request volume according to configured worker quotas. - Weighted Traffic Counting (
mod_lbmethod_bytraffic): Balances based on transfer volume in bytes. - Pending Request Counting (
mod_lbmethod_bybusyness): Tracks active queue depth and pending requests across workers. - Heartbeat Traffic Counting (
mod_lbmethod_heartbeat): Relies on heartbeat data exchange.
The Request Counting Algorithm (mod_lbmethod_byrequests)
The request counting scheduler (mod_lbmethod_byrequests) splits requests among backend workers so each node receives its configured share. As documented in the Apache mod_lbmethod_byrequests documentation, this scheduler uses two core metrics:
lbfactor: The normalized work quota representing the worker’s relative share of the workload.lbstatus: The worker’s current urgency level to fulfill its quota.
For each request cycle, the scheduler evaluates all available workers using the following loop:
for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factorBecause lbfactor values are normalized relative to one another, configuring workers with quotas of 25, 25, 25, 25 produces the exact same schedule as 1, 1, 1, 1. If a worker with lbfactor=4 is grouped alongside two workers with lbfactor=1, the weighted node will receive four times the requests on average.
Handling Worker Disablement and Asymmetric Quotas
If a member worker becomes disabled, the scheduler automatically continues cycling requests among the remaining active workers without breaking the quota proportions. In an asymmetric cluster with two workers where worker a has lbfactor 70 and worker b has lbfactor 30, the algorithm executes 10 iterations where 7 requests route to a and 3 requests route to b before lbstatus returns to zero and the pattern repeats.
Configuring Sticky Sessions with Cookies and URL Parameters
When backend applications store session state locally, subsequent requests from the same client must reach the same backend worker. As explained in the mod_proxy_balancer manual, IP-based mapping can lead to uneven distribution behind forward proxies or session disconnects on dynamic client IP changes. Instead, mod_proxy_balancer implements stickiness via cookies or URL encoding.
The balancer reads the session identifier using the stickysession attribute defined in ProxyPass or ProxySet, matching the identifier value against the worker’s route attribute. When both cookie headers and URL parameters are supported simultaneously, configure both separated by a pipe delimiter (|). For Java servlet containers (such as Apache Tomcat) that append semicolon path delimiters (;jsessionid=...), enable scolonpathdelim=On:
ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.1.50:80" route=node1
BalancerMember "http://192.168.1.51:80" route=node2
</Proxy>If both the cookie and the URL request parameter provide routing data on the same incoming request, mod_proxy_balancer prioritizes the value from the request parameter. If a session does not yet have an established route or if the worker route changes, the environment variable BALANCER_ROUTE_CHANGED is set to 1.
Enabling Dynamic Worker Management
To inspect and adjust cluster members without editing server configuration files or restarting Apache, administrators can enable the Balancer Manager interface. According to the Apache documentation, this management interface requires both mod_status and mod_proxy_balancer.
You can enable the browser interface with a restricted <Location> block in httpd.conf:
<Location "/balancer-manager">
SetHandler balancer-manager
Require host example.com
</Location>Through this interface, operators can change an individual member’s balance factor or place a worker into offline mode. Note that only balancer clusters defined outside of <Location ...> containers can be managed dynamically by the Balancer Manager tool.
Text version of the diagrams
- Worker Quotas and Request Share: Quota — Worker lbfactor share; Scheduler — Highest lbstatus selected; Request Share — Relative distribution over time
- Two Sticky-Session Inputs: Cookie — stickysession value; URL Parameter — Optional route value; Worker Route — Matches configured route
Research Method and Limitations
This explainer was prepared entirely from the public Apache HTTP Server 2.4 reference documentation for mod_proxy_balancer and mod_lbmethod_byrequests. No hands-on lab tests, throughput benchmarks, or uptime evaluations were performed. The supplied competitor tutorial excerpt contained generic promotional page copy without technical reverse proxy instructions. Explanations of other scheduler modules (mod_lbmethod_bytraffic, mod_lbmethod_bybusyness, and mod_lbmethod_heartbeat) and secondary failover directives are limited strictly to what is referenced in the visible official excerpts.
