alles eine frage, des konzeptes
war ja auch erst einmal nur ein test....
mal sehn was kommt
alles eine frage, des konzeptes
war ja auch erst einmal nur ein test....
mal sehn was kommt
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
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...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.
grüsse Manu
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
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
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
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.
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)
quatsch
das ist kein problem...
wie macht das ein provider bei 400 kunden a 2 datenbanken, die auf einem server sind??
kW
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
lol oops
war ich gestern so besoffen ;)
sorry, aber es sollte egal sein, ob man 3 oder 300 tabellen hat...
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.
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
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 ... ;)
Als nachtrag zu:
Das ist ein Problem am monitor, dass die anderen drei alamierungen nciht gestartet werden, wegen den 30 sekunden....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
und ManuelW
maul nicht so herrum, sondern fang an selbst zu programmieren!:!:!:!:
Aktive Benutzer in diesem Thema: 2 (Registrierte Benutzer: 0, Gäste: 2)