<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.24"> <TITLE>RE : [Nagios-devel] host_name and service_description examples</TITLE> </HEAD> <BODY> > I don't want to spend too much time trying to optimize the CGI speed, > as I am very much wanting them to disappear and be replaced by a new > interface soon. A DB backend makes the most sense for this, and > projects like nagios-db are a good start. I don't understand why the replacement of the CGIs by a new PHP UI seems to imply the replacement of the current transmission mechanism by a DB back-end. Does it mean that the new UI will directly access the DB ? Why don't we define an intermediate layer and an API for the UI to access object and status data ? This way, the user could choose between different communication channels. The DB would be one of the available channels, the core would feed any channels you choose to configure and the channel from which the UI would take its data is also a configuration choice. The central point here is performance. For a configuration with several thousands of hosts and services, how much improvement do you expect from a DB back-end ? If the UI is not at least 20 times faster (on the same hardware), we still have the same problem as now (with plain text files). I proposed an idea, which is totally compatible with a new UI. This way, I am sure to improve the read speed by a factor of 30 at least. I am currently rewriting it in order to remove the alignment problems inherent to the 'generic object' approach. It also removes much CPU time from the core (writing status data is about 15 times faster). If you think that this work is definitely useless, please let me know and I will forget it. Regards </BODY> </HTML>