CGI Speed

[Joe Rouvier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



The speed of the CGIs seems to have increased with the addition of
Daniel Drowns chained hashes, but there still seems to be a bottleneck
here. Based on my profiling of a couple of the CGIs, it looks like much
of the time is being spent loading and parsing the config files and the
status file.

While there are still some performance gains available by further code
optimization, we are quickly approaching a point of diminishing returns.
No matter how fast or efficient the code, parsing text and checking for
errors is always going to be relatively expensive. I see that CGI
rewrite is planned for 3.0, and would therefore like to offer my ideas
regarding CGI speed before the plan solidifies too much.

As I understand it, the CGIs need to parse the configs to determine what
services / hosts exist and to enforce access control on those services /
hosts. The status file is examined for obvious reasons& I propose that
the new CGIs not read files at all (at least host and service def
files). Instead a backend daemon would exist that stores the parsed
config and current status in memory and serves this to CGIs as
requested. This daemon could track current service status by ether
watching the nagios log, asynchronously loading that status file or
listening on a pipe / TCP socket / etc (my favorite). The CGIs would
contact the backend via TCP sockets. In theory this would allow
status.cgi to ask the backend Gimmie all current data about
myhost.mycorp.com that user bob can see, and get a quick response
without having to know about the thousands of other hosts and services.

Another benefit I see from this approach is that your webserver now no
longer needs to reside on the same box that is running the main nagios.
- From a scalability perspective this is a definite plus. Additionally,
while Im dreaming here, whats to prevent one backend from tracking
more than one nagios? This lends itself to some interesting new facets
to the current distributed monitoring paradigm.


- --
Joe Rouvier
Systems Administrator
Netli.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/kBuSd8npNR8ktbcRAuD6AKCQR7MCU8w5wvb34qSdn6bp53ty/ACdETEz
uTdcbbl4XDfUUdJ61nKofMQ=
=FlOH
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com