httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Temme <>
Subject Re: svn commit: r1228700 - in /httpd/httpd/trunk/docs: STATUS manual/mod/mod_heartbeat.xml manual/mod/mod_heartmonitor.xml manual/mod/mod_watchdog.xml manual/mod/mod_watchdog.xml.meta
Date Sun, 08 Jan 2012 00:04:51 GMT

On Jan 7, 2012, at 1:08 PM, Rainer Jung wrote:

>> hook handler prototypes are?  That's more like developer documentation.  Thoughts?
> I don't know about the history of similar decisions, but IMHO what you wrote is good
enough for 2.4.0.

Sounds good.

>>> +<p>The interval of 1 seconds is controlled by the HEARTBEAT_INTERVAL
>>> +compile time define.  This is not currently tunable at run time. To make
>>> +this module send the status packet more often, you must add to the
>>> +CFLAGS used to compile the module to include:</p>
>>> +<example>-DHEARTBEAT_INTERVAL=3</example>
>>> +<p>Would cause the broadcasts to be sent every 3 seconds.</p>
>>> +</section>
> "more often" than 1 second does not match the example "3 seconds" ;)
> I guess more often is not possible (if resolution is seconds), so it would be "less often"?
> More important: I think this is totally wrong. The define exists, but I couldn't find
any place in the code, which is influenced by it. I *guess* it uses the global watchdog interval
configured for mod_watchdog.

Yep, it's not used.  And WatchdogInterval in mod_watchdog should do the trick.  Perhaps an
early approach soon abandoned?  Removed from docs.  

>>> +<p>The<directive>HeartbeatAddress</directive>  directive specifies
>>> +multicast address to which<module>mod_heartbeat</module>  will send
>>> +status information. This address will usually correspond to a configured
>>> +<directive module="mod_heartmonitor">HeartbeatListen</directive>
 on a
>>> +frontend proxy system.</p>
>>> +<example>
>>> +HeartbeatAddress
>>> +</example>
>>> </usage>
>>> </directivesynopsis>
> Should we note, that Multicast needs to be enabled on both notes and routing needs to
be set up, so that the multicast packets from the origin server can reach the proxy? On the
one hand it is obvious, on the other hand not unlikely to be the typical first problem people
run into.

I'm +1 on a note, but don't think we should tell the story on setting up IP Multicast.  I
omitted this mainly because I don't know the story well enough.  Same for IPv6 address examples.

>>> +<note type="warning">
>>> +        To use<module>mod_heartmonitor</module>,
>>> +<module>mod_status</module>  and<module>mod_watchdog</module>
>>> +        must be either a static modules or, if a dynamic module, it must
>>> +        be loaded before<module>mod_heartmonitor</module>.
>>> +</note>
>>> +
> ??

The README talks only about mod_status.  I added mod_watchdog because mod_heart* has a hard
dependency on its symbols.  The mod_status dependency is not hard (mod_heartbeat loads without
mod_status loaded, or with mod_status later in the config), but not having actually run this
I don't know what more subtle issues might arise. 

Removed the orphaned singular "it" must be loaded.

>>> +<example>
>>> +    HeartbeatListen
>>> +</example>
> Same remark concerning the use of multicast as above.
>>>     <p>  This module is inactive until this directive is used.</p>
>>> </usage>
>>> @@ -88,7 +100,7 @@ heartbeat requests to this server</descr
>>>     <p>The<directive>HeartbeatMaxServers</directive>  directive
specifies the
>>>     maximum number of servers that will be sending requests to this monitor
>>>     server.  It is used to control the size of the shared memory allocated
>>> -    to store the heartbeat info.</p>
>>> +    to store the heartbeat info when<module>mod_slotmem_shm</module>
 is in use.</p>
> Can this be changed using graceful restart? Only for flat file or also for shm?

This gets set up in the post_config hook handler.  I forget whether that gets called on a
graceful, and have not analyzed whether the graceful restart case gets handled properly. 
I suspect this depends on the behaviour of the slotmem provider.  

In the file case, it seems that very few assumptions about the state of the world are made.

> Typo: "corrspond" -> "correspond"

Thank you.

> Additional info: it seems the data used for the load balancer is updated about every
5 seconds (define HM_UPDATE_SEC). More precisely it seems the heartmonitor is called by watchdog
(with interval 0 seconds, but watchdog sleep at least 100ms), then updates the data from what
is had previously read, then loops for 5 seconds reading new data and then returns to watchdog.
This is done one one thread per child, but a mutex guarantees, that it only runs in one child
at every time. Hope I'm right.

I hope so, too.  

> Furthermore the heartmonitor contains some additional code to handle POST requests directed
to it and reading usage data directly from the POST body (in addition to the multicast method).
> I think the current info in mod_lbmethod_heartbeat.xml is confusing. It contains:

I did not edit that doc.

> "This modules load balancing algorithm favors servers with more ready (idle) capacity
over time, but does not select the server with the most ready capacity every time.  Servers
that have 0 active clients are penalized, with the assumption that they are not fully initialized."
> As far as I can see in the code, it randomly chooses one of the idle origin server slots
based on the last received heartbeat data. Another equivalent formulation would be: it does
a weighted balancing to the origin servers, where the weights are proportional to the idle
(ready) slots reported with the last heartbeat message.
> I couldn't find code that penalizes servers with 0 active clients.

See Eric's response. 

> It seems the heartbeat lb opens the data file for each request. So if I'm right, using
slotmem is highly recommended for performance reasons.

That seems to be a safe bet.

>>> +<usage>
>>> +Sets the interval at which the watchdog_step hook runs.  Default is to run every
>>> +second.
>>> +</usage>
>>> +</directivesynopsis>
>>> +</modulesynopsis>
>>> +
> We could mention, that there are two ways (and APIs) a module can use mod_watchdog. Either
synchronously called every watchdog interval seconds, or running on a separate thread called
every interval seconds, where interval is given during the setup.
> Furthermore modules can tell mod_watchdog, whether the tasks should be run in each child
independently, or coordinated by a mutex.

Again, that would be Developer Documentation.  Should "we" put something under docs/manual/developer
to discuss how the module is used?


PGP FP: FC5A 6FC6 2E25 2DFD 8007  EE23 9BB8 63B0 F51B B88A

View my availability:

View raw message