Seite 2 von 25 ErsteErste 12345678910111213141516 ... LetzteLetzte
Ergebnis 16 bis 30 von 361

Thema: Monitor mit Datenbank-Unterstützung

  1. #16
    Registriert seit
    05.01.2004
    Beiträge
    97
    alles eine frage, des konzeptes
    war ja auch erst einmal nur ein test....

    mal sehn was kommt

  2. #17
    Registriert seit
    07.09.2003
    Beiträge
    694
    Ich hab das Ganze bei mir mal ausprobiert. Ich mußte leider feststellen, daß monitor nicht gerade schnell batches (bzw. shell-scripte) abarbeitet. Wenn es gleichzeitige Alarmierungen bei uns gibt, dann schafft es monitor gerade einmal, von 4 Rufen einen in MySQL einzutragen. Das System ist ein 400MHz PII mit 196MB RAM und SuSE 8.2 prof. ohne KDE und Gnome, nur mit einfachstem X (wird nicht genutzt, weil es ein reiner Server ist).
    Ansonsten ist mir aufgefallen, daß ich eine Menge ändern mußte, damit die PHP-Scripte bei mir liefen. Z.B. mußte ich die ganzen Variablen, die übergeben wurden umändern in das neue Request-Array (z.B. muß aus $page werden $_REQUEST['page']) Sonst läuft das Ganze nicht. Session-Variablen mußten ebenfalls geändert werden (z.B. $status zu $_SESSION['status']). Ganz schöne Arbeit, das alles rauszupulen. Ich denke, jetzt hab ichs. Was mir noch fehlt, ist die Beachtung von Alarmierungstypen für verschiedene Zwecke, so wie man es in der .monrc formulieren kann, beispielsweise Typ 3 für bestimmte Melder = "NEF-Notfalleinsatz" und Typ 3 für andere Melder = "TH groß" usw.
    Vielleicht läßt sich das Ganze ja doch so hindrehen, daß es direkt aus der .monrc ausliest, das wäre sicher ein deutlicher Geschwindigkeitsvorteil.

    Gruß
    Funkwart

  3. #18
    Registriert seit
    12.05.2004
    Beiträge
    341
    Original geschrieben von funkwart
    [B]Ich hab das Ganze bei mir mal ausprobiert. Ich mußte leider feststellen, daß monitor nicht gerade schnell batches (bzw. shell-scripte) abarbeitet. Wenn es gleichzeitige Alarmierungen bei uns gibt, dann schafft es monitor gerade einmal, von 4 Rufen einen in MySQL einzutragen.
    Genau das meinte ich, deshalb wäre es wohl am sinnvollsten, wenn jemand der c++ coden kann das direkt in das output modul rein schreibt...


    grüsse Manu

  4. #19
    Registriert seit
    05.01.2004
    Beiträge
    97
    also bei mir kommen immer in 2 sekunden abstaenden eine alamierung, und beide stehen drinm cih habs allerdings auch noch keinen benchmark gemacht mal sehn, villeicht bekomme ich mal das programm erweitert
    oder ich rede mal mim markus
    ersteinmal muss ich cmi haber verabschieden wegen umzug viel zu tun
    aber ich werde weiterarbeiten...

    @funkwart du kannst deine php.ini auch abaendern ;)
    aber schick mir mal das abgeaenderte
    j at dinspel dor com

    gruss Jens

  5. #20
    cwh Gast
    Dateien sind mit Sicherheit nicht schneller als Datenbankabfragen.

    Du solltest die ganzen Berechnungen und Auswertungen nicht in PHP machen, sondern den Job die Datenbank erledigen lassen. Dann wird das ganze so richtig flink.

    Wenn mir jemand ein paar Test-Datensätze zur Verfügung stellt, dann kann ich das auch mal ausprobieren und SQL-Seitig evtl. ein wenig helfen.

    Grüße,
    Christopher

  6. #21
    Registriert seit
    12.05.2004
    Beiträge
    341
    Tja, was die Datenbank bzw eine Auswertung mit php am Ende betrifft kann ich mich auch gern zur Verfügung stellen.

    Aber wie willst du die Datenbank füttern, wieder über ein shellscript? Ich denke das muss in die Monitorausgabe direkt rein, dort wo die Logfiles auch geschrieben werden, sonst wird das nix mit dem Speed. Leider hab ich nicht sehr viel Plan von C.

    Hast du denn schon ein paar Testdaten bekommen ?

    Meld dich einfach mal bei mir wenn du noch Hilfe oder was brauchst.

    gruss Manu

  7. #22
    Registriert seit
    05.01.2004
    Beiträge
    97
    Das bissl eintragen ist nciht das thema....

    und das problem mit der auswertung kann man auch ohne php machen ist nur mehr aufwand..
    eigendlich war es damals nur fuer mich gedacht und ich haette nie gedacht, dass das tool so viel rechenleistung braucht naja is eben mist programmiert ;)


    ich stelle mir das in etwa so vor... je schleife eine tabelle mit den namen: schleife_1234567
    das select * from schleife_1234567 where datum='10.10.1001' braucht keine rechenleistung...

    mit dem eintrag in die tabelle wird auch gleich die statistik geschrieben, so hat man kein problem mehr, dass man 1000 anfragen..

    so in der art stell ich mir das im moment vor..


    kW.

  8. #23
    Registriert seit
    12.05.2004
    Beiträge
    341
    lol um gottes willen, je schleife eine tabelle geht gar nicht...

    ich habe hier ca 300 Schleifen, dazu noch Sirenen und Fahrzeuge... das geht auf keinen Fall.

    3 Tabellen is ok

    1x pocsag
    1x zvei
    1x fms

    dann noch paar Tabellen für die Stats, kommt drauf an was die zeigen sollen, wobei ich auch keine Stats brauche und diese per kleinem php script einmal nachts erstellt werden können, diese last braucht man nich an den monitor geben.

    das reicht vollkommen. Man kann ja dann am ende nen kleines php Script bauen was die Datensätze Archiviert, welchen einmal mntl läuft. Aber die DB geht ein mit ca 700-800 Tabellen :P

    grüsse Manu
    Geändert von ManuelW (19.08.2004 um 22:04 Uhr)

  9. #24
    Registriert seit
    05.01.2004
    Beiträge
    97
    quatsch

    das ist kein problem...


    wie macht das ein provider bei 400 kunden a 2 datenbanken, die auf einem server sind??


    kW

  10. #25
    Registriert seit
    12.05.2004
    Beiträge
    341
    aiai, du solltest dich vielleicht mal etwas mit Datenbanken und deren Aufbau beschäftigen ;)

    Es gibt auf einem Datenbankserver ne Struktur von

    mehreren Datenbanken (pro Kunde eine wenn es um deinen Anbieter geht),
    mehrere Tables (Tabellen) pro Datenbank,
    und mehrere Spalten pro Tabelle...

    Bei nem Provider hat jeder Kunde eine eigene Datenbank pro Server in welcher er dann seine Tabellen hat...

    und nach deiner Aussage jetzt würdest du sogar pro Schleife eine Datenbank erstellen lol

    naja sorry, aber lies dich da vielleicht mal etwas ein und erkenne den Aufbau einer DB.

    grüsse Manu

  11. #26
    Registriert seit
    05.01.2004
    Beiträge
    97
    lol oops
    war ich gestern so besoffen ;)

    sorry, aber es sollte egal sein, ob man 3 oder 300 tabellen hat...

  12. #27
    Registriert seit
    12.05.2004
    Beiträge
    341
    sollte es nich, zumal es weit über 300 sind ;)

    auoußerdem ist es für ne Abfrage am Ende viel Systemlastiger wenn ich mir alles von einem Tag anschauen möchte und der 500 Tabellen abfragen muss, als wenn er in einer Tabelle schaut.
    Dazu kommt, du mußt dür jede Tabelle ne extra Abfrage starten, glaube da brechen so manche "klein betückte Rechner" schnell mal zusammen ;) und es ist nicht im sinner einer relationalen Datenbank optimiert programmiert.

  13. #28
    Registriert seit
    05.01.2004
    Beiträge
    97
    sein koennte...

    man koennte auch eine ramdisk erstellen ;) und darin die daten speichern ...

    was meint ihr, wie eine datenbank daten speichert??? im ram in der cpu??
    nein auch in dateien, nur hat man bei einer datenbank nicht das problem alles neu erstellen zu muessen...

    wie gesagt, ich wuerde es so machen...


    je schleife eine tabelle, so kann man die gesamten daten speichern, und schnell abrufen...


    und fuer die statistik, k/a, obs da ein funktion gibt, womit man die werte +1 setzen kann...

    zum thema monitor habe ich nur das problem, dass die alamierungen zwar alle in der log stehen, aber leider nicht jede in die datenbank eingetragen wird..



    kW

  14. #29
    Registriert seit
    12.05.2004
    Beiträge
    341
    naja, ich sag jetzt einfach mal "lol" und laß das so stehen...

    ich denk du solltest dich vielleicht doch nochmal über einige grundlegende Dinge die Datenbanken betreffen informieren.

    nich böse gemeint, nur find ich deine Vorstellung etwas ... ;)

  15. #30
    Registriert seit
    05.01.2004
    Beiträge
    97
    Als nachtrag zu:

    Original geschrieben von funkwart
    Ich hab das Ganze bei mir mal ausprobiert. Ich mußte leider feststellen, daß monitor nicht gerade schnell batches (bzw. shell-scripte) abarbeitet. Wenn es gleichzeitige Alarmierungen bei uns gibt, dann schafft es monitor gerade einmal, von 4 Rufen einen in MySQL einzutragen. Das System ist ein 400MHz PII mit 196MB RAM und SuSE 8.2 prof. ohne KDE und Gnome, nur mit einfachstem X (wird nicht genutzt, weil es ein reiner Server ist).
    Ansonsten ist mir aufgefallen, daß ich eine Menge ändern mußte, damit die PHP-Scripte bei mir liefen. Z.B. mußte ich die ganzen Variablen, die übergeben wurden umändern in das neue Request-Array (z.B. muß aus $page werden $_REQUEST['page']) Sonst läuft das Ganze nicht. Session-Variablen mußten ebenfalls geändert werden (z.B. $status zu $_SESSION['status']). Ganz schöne Arbeit, das alles rauszupulen. Ich denke, jetzt hab ichs. Was mir noch fehlt, ist die Beachtung von Alarmierungstypen für verschiedene Zwecke, so wie man es in der .monrc formulieren kann, beispielsweise Typ 3 für bestimmte Melder = "NEF-Notfalleinsatz" und Typ 3 für andere Melder = "TH groß" usw.
    Vielleicht läßt sich das Ganze ja doch so hindrehen, daß es direkt aus der .monrc ausliest, das wäre sicher ein deutlicher Geschwindigkeitsvorteil.

    Gruß
    Funkwart
    Das ist ein Problem am monitor, dass die anderen drei alamierungen nciht gestartet werden, wegen den 30 sekunden....

    und ManuelW

    maul nicht so herrum, sondern fang an selbst zu programmieren!:!:!:!:

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •