httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Houser, Rick" <>
Subject RE: [users@httpd] Problems with Event MPM Performance Tuning in 2.4.18
Date Mon, 06 Jun 2016 14:48:03 GMT
> So afaik the current 2.4 behavior is to enforce the minimum number of spare threads as 
> ThreadsPerChild * num_buckets 
> with num_buckets equal 1 if you are not leveraging SO_REUSEPORT (
This means that if you have only > one busy thread the minimum number of httpd processes
running will be always two. The new threshold is the more conservative:
> ThreadsPerChild * (num_buckets - 1) + num_buckets
> In your case, with num_buckets = 1, the lower bound of min spare threads is one, enabling
the possibility to get down to only one httpd process (because the MinSpareThread lower bound
won't > mess with your Min/MaxSpareThread settings anymore). 
> More info in Yann's explanation:
> Let me know if it makes sense! If so, to fix your problem you'd need to apply the patch
to the httpd source and recompile or wait for the backport to be reviewed/merged into the
2.4.x branch (and released afterwards).
> Luca

Sorry for the delay.  My updated packages were installed over the weekend, and this does appear
to fix the issue with me for the normal num_buckets = 1 case (all I use).

I'm far from an expert on the feature here, but wouldn't this behavior with num_buckets >
1 still leave the workload unbalanced?  I thought the point per Yann's comment ("We want the
number of children processes to be a multiple of the number of buckets so to optimally accept
connections") was to balance the processes even between the listeners?  I get that the initial
startup case is fine, but in the case of num_buckets = 2, if thread usage gets to > 50%,
this would seem to spawn a third, potentially unwanted process, leaving the workers unbalanced
when the load really shouldn't be.  I would have thought the way forward is leaving the idle
thread minimum alone, forcing StartServers >= num_buckets, and enforcing a minimum process
count = num_buckets.  If process counts should be multiples of num_buckets, scaling any process
count expands/shrinks by num_buckets would seem to be the way to accomplish this.  I think
this would also need a check to ensure that MaxSpareThreads >= MinSpareThreads + num_buckets
* ThreadsPerChild + num_buckets.

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message