httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel <dferra...@gmail.com>
Subject Re: [users@httpd] Problems with Event MPM Performance Tuning in 2.4.18
Date Mon, 27 Jun 2016 08:30:07 GMT
As a real mitigation, maybe you could just use to mod_proxy and
mod_proxy_balancer, also those are not third party modules and probably
will render the same functionality you seek.

2016-06-27 9:50 GMT+02:00 Luca Toscano <toscano.luca@gmail.com>:

>
>
> 2016-06-06 16:48 GMT+02:00 Houser, Rick <rick.houser@jackson.com>:
>
>> > 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 (
>> https://httpd.apache.org/docs/current/mod/mpm_common.html#listencoresbucketsratio).
>> 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:
>> http://svn.apache.org/viewvc?view=revision&revision=1737447
>> >
>> > 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.
>>
>>
> This time I should say sorry for the huge delay :)
>
> I started an email thread in dev@ as follow up to your questions [1] and
> Yann proposed a new MaxSpareThreads limit as you suggested in [2]. Credits
> to you for the idea of course, thanks a lot!
>
> I am going to update the related docs soon to warn users about how
> ListenCoresBucketsRatio changes the (Min|Max)SpareThreads calculations.
>
> Luca
>
>
> [1]:
> https://lists.apache.org/thread.html/53a4179f4afe9d1618a4475fa351f1e0ad141d8539beaf4f8332a96a@%3Cdev.httpd.apache.org%3E
> [2]: http://svn.apache.org/r1750218
>



-- 
*Daniel Ferradal*
IT Specialist

email         dferradal at gmail.com
linkedin     es.linkedin.com/in/danielferradal

Mime
View raw message