Wie geht man mit 0-Day Lücken um?

[Geigenberger]

Guten Morgen, Herr von der Burchard,

#Geigenberger...
Na ja, aber genau das ist ja wohl der Unterschied. Wieso benötigen andere Programme 8 Minuten und T2med nur 5 sek? ...

... vielleicht weil diese eine andere Datenbank verwenden?
Außerdem haben Sie ja mal geschrieben, dass bei T2Med die Clients ruhig etwas "schmalbrüstig" sein dürfen, der Server sollte aber leistungsfähig sein (Sie haben Ihre Server-Leistung hier irgendwann auch mal gepostet).
Warum wohl?: Die Clients haben nicht viel zu tun ( viewtopic.php?f=78&t=5516#p32750 ), der Server schon, denn da läuft ja die Datenbank "PostgreSQL".

...die Indizierung....also wir indizieren die Karteieinträge noch nicht einmal ...

... das macht die Datenbank auch ohne besondere Voreinstellung von sich aus. ... aber da kennen sich viele Leute hier sicher sehr viel besser aus als ich.
Aber nochmal: Damit möchte ich aber natürlich nicht die Qualität des Datenbank-Handlings von T2Med in Frage stellen:!!

Viele Grüße aus dem verregneten Bayern
A. Geigenberger

[DrHJvdB]

Ja,

die Schmalbrüstigkeit von Clients ist ja eben möglich, weil nur wenig Daten zum Client übertragen werden und auch keine große Rechenleistung am Client erforderlich ist. So arbeite ich ja seit Monaten mit diesem Lenovo-Mini-PC für 250,- Euro in einem Sprechzimmer und stelle keinerlei Unterschied zu einem 'richtigem' PC in einem anderen Sprechzimmer fest. Im Grunde könnte ich alle PCs durch solche Mini-Rechner austauschen (bis auf den Server natürlich).

Mein Server ist so ein Xeon mit 16 GB RAM mit WinServer 2012 R2, aber hardwaremäßig nix besonderes. Spannend ist für mich die Frage, wie T2med noch mehr flitzen würde, hätte ich eine SSD im Server. Das kommt gemeinerweise aber für mich nicht in Frage, weil ich dann sozusagen einen viel zu guten Eindruck bekäme und Schwächen der Programmierung kaum auffallen würden. Dann wär ja alles superschnell.

Deshalb ist es für mich wichtig, eher mit langsamer Hardware zu arbeiten: dann fallen unelegante Programmierungen erst auf. Früher, also ganz früher, habe ich das auch immer gemacht. Als schon alle Welt nicht nur 386er, sondern 486er oder gar Pentiums benutzte, habe ich bis zum bitteren Ende mit einem uralten 286er gearbeitet. Das war stets sehr aufschlussreich!!!

Das mit der Indizierung der Karteikarte prüfe ich noch einmal...

[DrHJvdB]

Ich habe nochmal mit einem Entwickler telefoniert:

Das war mein alter Eintrag:

Suchbeispiel Hypertonie:
Ich möchte wissen, bei wievielen Patienten seit 1990 das Wort Hypertonie vorkommt:
Ergebnis: 569 Patienten in 5.8 sek (Anderes Programm braucht 265 sek, gleiche Warnung zuvor)

Jetzt einen neuen Index über die Karteizeilen angelegt:
Ergebnis: 569 Patienten jetzt in 2.4 sek
also ungefähr Verdopplung der Suchgeschwindigkeit.

Ich nehm das mal zum Anlaß, um weitere Indes-Anlagen zu untersuchen. Hochspannend...

[Geigenberger]

... freut mich, wenn ich Ihr Programm mit meiner Anregung bereichern konnte
Aber jetzt ist noch klarer: Sie haben sicherlich ein gutes Programm, aber vielleicht eine noch bessere Datenbank, wobei aber 569 Datensätze nicht soo wahnsinnig viele sind.
A. Geigenberger

[DrHJvdB]

Ok,

anderes Beispiel: gerade suchte ich in allen Karteikarten aller Patienten nach dem Wort 'Schmerzen'

Gefunden wurden 2649 Patienten in 5.04 Sekunden

[DrHJvdB]

jetzt quäle ich T2med:

ic suche das Wort 'ein' bei allen Patienten.
Gefunden werden 4333 Einträge in 4.33 Sekunden

[DrHJvdB]

Lieber Herr Geigenberger,

Sie helfen echt! Das mit den Indexen ist wirklich hochspannend, danke für den Tipp!

Ein geänderter Index mit einer neuen Query findet jetzt in der gesamten Karteikarte aller Patienten seit 1990

das Wort 'ein' bei 4333 Patienten in nur noch 1.6 sek
und das Wort 'gestürzt' bei über 200 Patienten in 0.6 sek
die Diagnose Hypertonie bei über 670 Patienten in 0.7 sek
die Diagnose 'Klippel' bei einer Patientin in 0.67 sek (extrem seltene Diagnose eines Klippel-Trenauny-Weber-Syndroms)
die Ziffer '03003' bei über 1000 Patienten in 0.8 sek
die Ziffer '033042' bei über 700 Patienten in 0.7 sek

Wir sind noch am Basteln, ob's vielleicht noch schneller geht
Beste Grüße

[EWERKER]

Sie helfen echt! Das mit den Indexen ist wirklich hochspannend, danke für den Tipp!

Es passt auch nicht so ganz zum geschilderten Sicherheitsproblem von Systemen mit Java. Wir entwickeln auch ganz viel in Java und der 1. Schrei der Entwickler ist: ich brauche mindestens doppelt so viel RAM....egal wie viel drin ist.
Java ist schon ein ressourcenfressendes Ungeheuer, schon allein deshalb weil jeder Bytecode erst durch die JAVA-VM muss. Trotzdem kann man natürlich intelligent programmieren und sehr schnelle Programme machen. Keine Frage.

[DrHJvdB]

stimmt, eigentlich müsste man ein neuen Thread 'Suchen' oder so anlegen...

[DrHJvdB]

aber noch mal zum RAM:

serverseitig reichen aber echt 4 GB, clientseitig 2 GB.
Aber sicherheitshalber könnte man auch etwas mehr reinpacken...4 GB RAM kosten ja heutzutage recht wenig...gibt ja auch noch kaum aktuelle Maschinen mit weniger...

[Geigenberger]

...Sie helfen echt! Das mit den Indexen ist wirklich hochspannend, danke für den Tipp!...

Whow!!! Ich muss wirklich so richtig gut sein!. Da kann ich als "EDV-Amateur" den spezialisierten Datenbankprofis von T2Med erklären, wie sie Ihre Datenbank schneller kriegen. Aber Sachen gibt's auch: Indexe für Datenbanken und so....

A. Geigenberger

[DrHJvdB]

Sie SIND richtig gut...der Meinung war ich immer

[Sichel]

...Sie helfen echt! Das mit den Indexen ist wirklich hochspannend, danke für den Tipp!...

Whow!!! Ich muss wirklich so richtig gut sein!. Da kann ich als "EDV-Amateur" den spezialisierten Datenbankprofis von T2Med erklären, wie sie Ihre Datenbank schneller kriegen. Aber Sachen gibt's auch: Indexe für Datenbanken und so....

A. Geigenberger

Das finde ich aber auch etwas bedenklich. Aber bestimmt liegt es nur daran, dass das Team von T2W sich nur noch nicht um die Geschwindigkeit der DB gekümmert hat weil sie ja so schon so rasend schnell ist/war und es bisher dafür keinen Anlass gab...