host_name and service_description examples

[Fran=?utf-8?B?w6c=?=ois Laupretre]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20050614/45117faa/attachment.html>
-------------- next part --------------
Ce message et ses pièces jointes (le "message") est destiné à l'usage    
exclusif de son destinataire.                                            
Si vous recevez ce message par erreur, merci d'en aviser immédiatement   
l'expéditeur  et de le détruire ensuite. Le présent message  pouvant  
être altéré à notre insu,  CALYON Corporate and Investment Bank                              
ne peut pas être engagé par son contenu. Tous droits réservés. 
          
This message and/or any  attachments (the "message") is intended for     
the sole use of its addressee.                                            
If you are not the addressee, please immediately notify the sender and    
then destroy the message.  As this message and/or any attachments may 
have been altered without our knowledge,  its content  is not legally 
binding on CALYON Corporate and Investment Bank. All rights reserved.