It's also worth noting that there's no particular reason to avoid
developing other front-ends to Ganglia. If you'd rather build one your way
using a particular technology or library that better suits your needs, the
existing architecture makes it pretty easy for you to do so. Almost as if
it was designed that way. ;)
I am not exactly a charter member of the PHP fanclub myself. We use Python
a lot here internally, but I don't know how I'd feel about using mod_* for
something that could be processing a very large number of nodes.
But if we're going to talk about what language/platform combo would be best
for a Ganglia front-end app, in purely abstract terms (i.e. someone else
writes it :P ), I think I'd want to see the whole thing implemented as a
Java servlet. There'd be all kinds of speed benefits just from the
decreased overhead for each request, not to mention decoupling the XML/RRD
parsing and page rendering. In fact, it might even make sense to write the
metadaemon as child threads of the front-end (parsing the XML into an
internal data structure, and updating the RRD files every time the values
change - this way you're not parsing all the XML every time you hit Reload...).
On a (very) slightly less pie-in-the-sky note...
Has anyone considered the utility of being able to select a subset of
cluster/host/metric data from the metadaemon? In other words, you send a
command that limits display to values that have been updated in the last 60
seconds, or a particular cluster or host name. Any speed hit from building
the new response would probably be made up for in the front-end. If you're
viewing host details for one host out of a 900-host combined metadaemon XML
feed, and the front end only parses 30 metrics instead of 2700... well...
It would mean rewriting the listen thread of gmetad (and, simultaneously,
the front-end) to have a full-duplex conversation and there's some possible
gotchas there... but what the heck, this is the developer's list.
Anyway. Another great idea from the people who brought you beer milkshakes...
Federico Sacerdoti wrote:
Well there are a few reasons. I know only a cursory bit about xslt,
however, so let me know if I'm off base on any of these.
We chose PHP over XSLT because:
-PHP is faster, and more mature.
-Can handle CGI variables which keep state between different HTML views.
-Can read form data given by user.
-Can read in user-defined local configuration files from disk
(private_clusters, etc).
-Can call functions using local shell (for rrdtool graph, for example).
On the other hand, I think PHP is a cumbersome language. I have talked
about using mod_python, but the fact is, I would have to see a really
good reason for doing so, as it would take alot of work, and perhaps end
up being slower.
Hope this helps answer your question.
Federico
On Thursday, December 5, 2002, at 11:53 AM, [EMAIL PROTECTED] wrote:
The Ganglia web frontend uses PHP to transform xml to html (I think).
Why was that method chosen instead of using PHP to make calls to xslt
scripts to do the transformation? Is there a belief that PHP is better
than xsl for coding xml to html transformations? Does the Ganglia web
front end include transformations that aren't easily expressed in xsl?
Jonathan
Federico
Rocks Cluster Group, Camp X-Ray, SDSC, San Diego
GPG Fingerprint: 3C5E 47E7 BDF8 C14E ED92 92BB BA86 B2E6 0390 8845
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
