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 the >>> +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 239.0.0.1:27999 >>> +</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 239.0.0.1:27999 >>> +</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? S. -- scte...@apache.org http://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
