Hi Alex, Some thoughts...
On Tuesday 06 November 2007 20:23:50 [EMAIL PROTECTED] wrote: > I've been working on a list of ways to improve the PHP web frontend. > Just curious what every else thinks of these. > > - add support for a caching layer for generated graphs > Add code that allows caching of generated graphs, either on the > filesystem or in a memcache cache. When generating a graph, serve the > cached version if the refresh time for that metric has not passed. > > When lots of people viewing the same pages in the web frontend, this > would sometimes eliminate the need to call rrdtool, or even parse the > XML, to serve graphs. > Good idea! Perhaps you could also set the HTTP cache-control for these cached images to some sensible value. This would allow clients and proxies to cache the graphs Another potentially optimisation would be to be more clever with the page refresh. The currently default is every 300s for all pages. A simple improvement would be to increase this number when looking at longer periods (e.g. "last week" or "last month"): refreshing every 5-min when looking at a yearly plot doesn't make too much sense! Ideally, this should be tied into the corresponding RRA update rates. Since (for most people) gmetad will create these RRAs, we can probably include them as constants. > - Move the graph.php functionality into an OO class. > Create a base class that contains the basic functionality of drawing a > graph (like the rrdtool calls). Also provide an interface which > custom graphs would implement. People who are providing custom > metrics could also provide PHP modules to graph their metrics when > custom graphs are appropriate. If all graphs implement a common > interface its easier to plug in 3rd-party graphs into your existing > web app. If you've not seen it, this is similar to something I worked on. The MGRRDGraphBase class within muli-graph here: http://monami.cvs.sourceforge.net/monami/external/ganglia/ganglia/multiple-graphs.php?view=markup Here is an example of the class being used: http://monami.cvs.sourceforge.net/monami/external/ganglia/ganglia/mysql-graph.php?view=markup > Implementing interfaces would require PHP5, since the PHP4 object > model doesn't support them. PHP4 will be end-of-life on 12/31/2007 > (search for 'PHP 4 end of life announcement' on > http://www.php.net/archive/2007.php). Quite a few large PHP projects > have committed to being fully PHP5 by February of next year > (http://www.gophp5.org/projects). I think moving the ganglia web > application in this direction is a good idea. Yes, I was torn between keeping with PHP4 and using interfaces / abstract classes. In the end, I figured I could keep PHP4 as I could do without the "nice" PHP5 features (interfaces, abstract methods, ...) For the HTML/frame support (MGFrameBase) I used a simple skeleton method and expecting other classes to override them. For the RRD class (MGRRDGraphBase), there didn't seem much need for OO as I didn't need to extend any of the graphs. I used the OO class hierarchy (and MGBase) to keep colours common between the HTML-generating class and the Graph-generating class. > - Provide graphs as a web service > This would accept requests for metric data (XML, JSON, whichever), > generate a graph, and respond with a URL to the graph. This would > make it possible to embed metrics in other web applications (PHP or > non-PHP) without much fuss. Although specifically a Google invention, Gadgets supports this. There is some (admitidly ugly) support for this here: http://monami.cvs.sourceforge.net/monami/external/ganglia/ganglia/google.php?view=markup With Google Gadgets, one can embed them within third-party webpages. Google call this "Syndication". In practise, one just points at to the right bit of JavaScript (off of Google) and their javascript generates an iframe which the Gadget contents can sits within. > I'm imagining this would be built around the graphs-as-a-class idea > from the previous suggestion. Sounds good. > - Allow clients to reload graphs asynchronously. > I'm picturing opening a monitoring page, and have the page make AJAX > requests back to the server for each of the graphs to be displayed. > JavaScript on the client side would refresh each of the graphs > according to the refresh schedule of the metric being graphed. The > page itself would never refresh, but the graphs would periodically be > replaced with fresh data. The 'web service for graphs' idea above > would probably be a requirement to make this one fly. Hmm, sure, if you want to; but I don't think this one's really worth the effort involved. If one specifies the correct caching time for the static content (PHP page, logos, ..) then the refresh will only affect the graphs. If your graph-caching idea above is implemented, this would be (effectively) serving up static content, so should be pretty fast, too. > Providing some additional 'tooltip' data when rolling over the graph > (like when it was last refreshed, or when the next refresh is > expected) would probably be nice as well. Yup, that could be good. > - Allow rollover effects on graphs which display discrete data. > Someone sent a link to a Perl/rrdtool application that had this > feature a while ago. If we can't incorporate that project directly, > create something similar. There's some pop-up CSS support in MonAMI/external, if that's of any use. Cheers, Paul. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
