Client/Server Architektur realisieren - Ideen

[Dejan Vu]

Zitat von DJ-SPM:

Manchmal muss es sein, dass 500+ Einträge aus der DB geladen werden. Jeder Eintrag ist ein Objekt - sagen wir mal, ein Adressen-Objekt. Diese Liste nun in einen json-String zu konvertieren dürfte ziemlich aufwendig / unperformant sein, oder?

Wir leben im Zeitalter von GHZ-Prozessoren mit mehreren Kernen und 39+GB RAM (oder von mir aus auch nur 4 GB).

500.000.000 Objekte sind ein Problem, aber doch keine 500. Das macht mein Telefon sogar schon in <0.1ms (leicht übertrieben ausgedrückt).

Die Überlegungen sind grundsätzlich richtig (Ich hatte ähnliche bei meinem ersten N-Tier Projekt, wo ich dachte, XML würde alle Grenzen sprengen), daher mein Tipp:

Mach einfach Messungen. Prüfe, ab welchem Bereich Du meinst, Performanceprobleme zu bekommen. Versuche dann, diese Probleme zu bewerten: Sind diese im Betrieb derzeit erreichbar? Oder in absehbarer Zeit? Welche Maßnahmen kannst Du ergreifen (z.B. die Objekte zu cachen)? etc.

[Sir Rufo]

Egal ob Chat oder irgendwelche sonstigen Benachrichtigungen, dafür eine extra Service-Anwendung zu bauen und die Komplexität zu erhöhen halte ich für unklug.

Die REST-API weiß, ob eine bestimmte Aktion eine Benachrichtigung erfordert. Wenn, dann trägt diese das in die entsprechenden MessageQueues ein. Diese MessageQueues werden vom Client selber überwacht/abgefragt (Long Polling).

Ob diese Benachrichtigung nun eine Chat-Nachricht oder eine Änderung an dem Datensatz X betrifft spielt doch keine Geige. Das muss der Nachrichteninhalt hergeben.

Was du mit dem Änderungszeitpunkt anfangen möchtest ist mir auch noch nicht klar.

In einem System (speziell einem asynchronen) sollte jede Änderung (Nachricht vom Client an die API) den Zeitpunkt des Auftretens (ocurred) beinhalten. Die API fügt dann noch den Zeitstempel ein, wann das empfangen wurde (received) und trägt die Information ein.

(Muss ich erwähnen, dass die Zeitbasis immer UTC-bezogen sein sollte?)

Jetzt kommen wir zum eigentlichen Kern:

Gibt es in der API schon einen Eintrag, mit einem jüngeren ocurred, dann hat sich der Datensatz nicht verändert - die Historie hat sich sehr wohl verändert - und zieht somit keine weitere Aktionen der anderen Clients nach sich, es sei denn, die schauen sich die Historie an.

[Mavarik]

Zitat von DeddyH:

Vorsicht vor Optimierungen

OMG..

Zitat von clean-code-developer.de:

Optimierungen kosten immer viel Aufwand. Wer Vorsicht walten lässt, spart oft wertvolle Ressourcen für das, was dem Kunden wirklich nützt.

Ich habe schon lange nicht mehr so einen Blödsinn gelesen.

Aber Egal... Lassen wir das Thema - rege ich mich nur auf.

Zum Thema.

Wie hatte ich schon oben geschrieben..."Absender, Kommando, SeekNr, DatenbankID sind bei mir 7 Byte... "
Dann hänge noch die Nutzer Daten daran.. Aber bitte als Byte/Record/Stream, jag das Ganze durch einen Echtzeit Stream-Kompressor ala Telefon/Codec fertig.
Wenn du viele Datensätze hast kann Du auch einen Hardcore Kompressor nehmen. Die schnellere Übertragung macht die Zeit für das komprimieren wieder wett.

5000 Datensätze (Adresserecord) à 1024 Byte dann ggf. komprimieren mit i.d.R. Faktor 3:1 oder kleiner sind rund 1600 KB. Das macht nur Schwupti und ist da.

Ein Update auf diese 5000 Datensätz (z.b. Datum der letzten Rechnung oder was auch immer) - nicht 5000 Datensätz komplett Übertragung sondern:
ID, Feldname, Value... und schon habe ich das Datenvolumen von REST (wahrscheinlich 8k pro Datensatz) auf 30 Byte runtergebrochen...
Und da soll nochmal jemand sagen "Optimierungen kosten immer viel Aufwand."

Mavarik

[Dejan Vu]

Optimierung kosten Zeit. Programmierzeit. Wenn Du genügend davon hast, wunderbar. Andere müssen damit rechnen, haushalten etc. Bei professionellen amateurhaften Softwareentwicklern spielt die Resource 'Zeit' nun mal eine Rolle.

Und wenn ich dem Kunden sage: "Dein Tool verschickt nur noch 5kb anstatt vorher 15kb, kostet aber dafür einen Tagessatz mehr", dann schaut dieser mich etwas verdutzt an, knallt mir die Spec ins Gesicht, dreht sich um und sagt: "Das wars dann wohl". Wenn er freundlich ist.

In der professionellen amateurhaften Softwareentwicklung macht man genau das, was der Kunde will. Wer noch eins draufsetzt, macht es gut. Wer noch eins draufsetzt, macht es nachhaltig.

Steht in der Spec: Bitte Bandbreite optimieren, wird das gemacht. Steht es dort nicht, wird es nicht gemacht. Steht dort: Muss bei einer 100kbit-Leitung in 10 Sekunden durchrauschen, wird es gemacht. Steht dort nichts, schaut man sich um, was so usus ist ("allgemeiner Stand der Technik" oder fragt nach) und setzt dann ggf. nach Rücksprache um.

Wo ist da ein OMG, oder 'selten so einen Blödsinn gelesen'?

Edit: Noch ein kleines...

Zitat von Donald E. Knuth, 1974:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

[Mavarik]

Zitat von Dejan Vu:

Optimierung kosten Zeit.

Ich will Dir nicht schon wieder ein OMG schreiben... denn im Prinzip hast Du recht! Mein Standpunkt ist ein anderer.

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein "Beginupdate, EndUpdate" einer Liste bringt einen enormen Geschwindigkeitszuwachs und kostet keine Zeit.
Und stört auch nicht bei debuggen...
oder stört die Lesbarkeit des Codes...

Mavarik

[mkinzler]

Ich meine mal, das diese Optimierungen hier nicht gemeint sind.

[Dejan Vu]

Zitat von Mavarik:

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein sehr schönes Thema für einen eigenen Thread.

[Mavarik]

Zitat von Dejan Vu:

Zitat von Mavarik:

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein sehr schönes Thema für einen eigenen Thread.

Stimmt.. Hat hier nix zu suchen

[TheMiller]

Guten Morgen!

Nachdem ich den Thread nochmal komplett gelesen und mir über das Wochenende viele Gedanken gemacht habe, möchte ich nochmal zusammenfassen und konkrete Umsetzungsvorschläge anbringen:

* Auf dem Datenbank-Server wird eine REST-API eingerichtet. (Diese habe ich zum Glück schon aus einem anderen Projekt fertig). Die API deshalb, weil wir tatsächlich planen, noch andere Plattformen zu bedienen und die Wartung ist viel einfacher (Queries nur auf einer Plattform aktualisieren/erstellen). Long-Polling kann umgesetzt werden.

* Auf dem Windows-Server wird ein Server-Dienst laufen. Dieser dient auch als Zwischenschicht zwischen Clients und Datenbank-Server. Die Verbindung wird über TCP-Server/TCP-Client von Indy realisiert. Der Server-Dienst nimmt requests entgegen und verarbeitet sie. Diese Requests sind vom Typ TRecord und haben mindestens folgende Felder: Absender, Empfänger, Timestamp, request_id, request_str (json_string). So sollte eine exakte Zuordnung und Verarbeitung der Nachricht möglich sein (genauer ist das noch nicht durchdacht). Je nachdem, was der TRequest dem Server aufträgt, führt er die Aktion durch (Aktion mit anderen Clients oder Anfrage an die DB). Danach sendet er an den ursprünglichen Absender oder einen "Broadcast" TResponse zurück.

* Der Server-Dienst prüft die Erreichbarkeit des Datenbank-Server (vllt. Ping, oder über eine UniDAC-Methode (weiß ich noch nicht)). Ist er mal nicht erreichbar, sendet er einen "Broadcast" (eher eine TCP-Nachricht an alle Clients), dass der Server weg ist. Diese zeigen es dann in der GUI an. Vllt. empfängt der Dienst Datenbank-Anfragen, die er zurückhalt, bis die Verbindung wieder aktiv ist. Weitere Aufgaben der Windows-Dienstes sind zeitgesteuerte kleinere Backups (kein Image o.ä.)/Aufräumarbeiten, Benachrichtigungssysteme etc.

* Benachrichtigungssysteme:
- User A und B haben Modul-1 offen. User B ändert Daten über Modul-1. Nun sendet der Dienst eine TCP-Nachricht an alle User, die Modul-1 offen haben, damit sie aktuelle Daten laden können. Bzw, der Server lädt einmal die aktuellen Daten und sendet sie schon an den User.
- Ein wichtiges Modul ist gerade nicht geöffnet. Es wurden aber von B wichtige Daten für A hinterlegt. So wird User A vom Server benachrichtigt, dass wichtige Daten vorliegen.

* Optimierungen: Da z.T. auch über außenstellen gearbeitet wird, ist VPN sehr wichtig (sensible Daten und einfachere Kommunikation). Die Daten sollen also klein gehalten werden. Ein Zwischending zwischen den hier genannten Vorschlägen wird einzuhalten sein. Wenn man gut plant, mitdenkt und den rest durch ausprobieren ermittelt, dann wird es kein Thema sein.

Soweit bin ich erstmal. Hab nur eine Frage zum Format der TCP-Anfragen. Wie soll ein Kommando an den Server aussehen? Es wird ja vermutlich ein String sein. Soll er wie Parameter in URLs aussehen (module=abc&action=getImportantData&dataId=123), soll er in URL-Form sein (/ABC/getImportantData/123), oder soll es ein Record sein TParams (Modul: abc, Action: xyz...). Was macht da Sinn? Man müsste immer mit Explode etc. arbeiten. Habt ihr dazu noch weitere Vorschläge?

Vielen Dank für die rege Anteilnahme!

[Mavarik]

Zitat von DJ-SPM:

Wie soll ein Kommando an den Server aussehen?

Immer ein Record nehmen... Da hast Du alle Felder getrennt und musst nicht extra wieder einen String analysieren.

Mavarik