Bug#307998: munin-html should be smarter about re-generating the HTML files
* Marc Haber But it still hurts to have that done every five minutes. Additionally, it is prone to confuse host-based IDSses which would need to be manually configured to ignore the html files changing ctime and inode all the time. Also, it breaks web caching. Well, there's a reason for the name of the /var directory. If an IDS doesn't expect data in there to change, it's broken. And that it hurts to generate the HTML file is in my opinion a gross exaggeration, substituting some values into the templates and writing them out to disk asynchronously isn't an expensive operation either. I don't really know if the performance gain from using the stat+compare approach will be worth it - I've never seen a modern machine having any difficulty running munin-html. But I shall discuss it with Jimmy when he returns. A fully-dynamic site is the optimum. Smokeping could serve as example. I agree, and I will try to convince Jimmy to implement that. :-) However it won't make it to the 1.2.x branch (too intrusive), but Etch is still far away so there's no rush. 1.4.x will probably be released sometime this summer, hopefully with the CGI capable of making the HTML pages as well. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307998: munin-html should be smarter about re-generating the HTML files
severity 307998 wishlist tags 307998 upstream quit * Marc Haber munin-html does always create completely new HTML pages. This is a waste of resources. munin-html should detect whether the configuration has changed, and only re-generate the HTML pages in that case. I don't consider this a bug, rather a design weakness that I agree could be improved. I've therefore changed the severity to what I feel is appropriate. Anyway, I'll make sure Jimmy (main upstream guy) will see this when he returns from his holidays. I don't feel it's important enough to push it if he says no, though - generating the HTML pages is far from a heavy task, it could even be that the resource savings you'd get from introdusing the logic you ask for are insignificant or even non- existent. It would also kill the last updated timestamp at the bottom of each page, which I at least consider a nice thing to have. Perhaps it could be implemented as an option, or even merged into the CGI so you'd have the choice between a fully-static site which updates once in a while, or a fully-dynamic site which updates upon request. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307998: munin-html should be smarter about re-generating the HTML files
On Mon, May 09, 2005 at 08:28:54AM +0200, Tore Anderson wrote: * Marc Haber munin-html does always create completely new HTML pages. This is a waste of resources. munin-html should detect whether the configuration has changed, and only re-generate the HTML pages in that case. I don't consider this a bug, rather a design weakness that I agree could be improved. I've therefore changed the severity to what I feel is appropriate. Anyway, I'll make sure Jimmy (main upstream guy) will see this when he returns from his holidays. Agreed. I don't feel it's important enough to push it if he says no, though - generating the HTML pages is far from a heavy task, But it still hurts to have that done every five minutes. Additionally, it is prone to confuse host-based IDSses which would need to be manually configured to ignore the html files changing ctime and inode all the time. Also, it breaks web caching. it could even be that the resource savings you'd get from introdusing the logic you ask for are insignificant or even non- existent. That logic is a stat and a comparision. Not quite expensive operations. It would also kill the last updated timestamp at the bottom of each page, which I at least consider a nice thing to have. A timestamp is included in the rrd graphs, which is quite sufficient, IMO. Perhaps it could be implemented as an option, or even merged into the CGI so you'd have the choice between a fully-static site which updates once in a while, or a fully-dynamic site which updates upon request. A fully-dynamic site is the optimum. Smokeping could serve as example. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307998: munin-html should be smarter about re-generating the HTML files
Package: munin Version: 1.2.3-1 Severity: normal Hi, munin-html does always create completely new HTML pages. This is a waste of resources. munin-html should detect whether the configuration has changed, and only re-generate the HTML pages in that case. Greetings Marc -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.9-zgserver Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages munin depends on: pn libdigest-md5-perl Not found. ii libhtml-template-perl 2.6-2 HTML::Template : A module for usin ii librrds-perl 1.0.49-1 Time-series data storage and displ pn libtime-hires-perl Not found. ii perl [libstorable-perl] 5.8.4-8Larry Wall's Practical Extraction ii perl-modules 5.8.4-8Core Perl modules -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
