AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Client/Server Architektur realisieren - Ideen
Thema durchsuchen
Ansicht
Themen-Optionen

Client/Server Architektur realisieren - Ideen

Ein Thema von TheMiller · begonnen am 5. Dez 2014 · letzter Beitrag vom 28. Dez 2014
Antwort Antwort
Seite 1 von 2  1 2      
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.165 Beiträge
 
Delphi 10.3 Rio
 
#1

AW: Client/Server Architektur realisieren - Ideen

  Alt 10. Dez 2014, 09:38
So. Ich werde definitiv eine Zwischenschicht einbauen. Es hat wirklich viele Vorteile. Sie wird höchstwahrscheinlich in PHP erstellt, also eine REST-API. Passt auch gut, da ich eine solche schon mehrfach umgesetzt habe.

...

Mir geht es hauptsächlich darum, ob die Kommandos in der o.g. Form eine gute Idee sind, oder ob ich ein anderes System/Format nutzen sollte. Dieser String könnte auch durchaus anders aussehen, z.B. so: "/user/registerOnline/192.168.1.6".
Oder man sendet gleich ein Record bzw. json-array. Es ist halt erstmal das Problem da, dass nicht absehbar ist, wie viele Parameter übergeben werden müssen, geschweige denn ganze ObjectLists.
Wie sieht dann Dein Daten-Flow aus...

1. Optimierte Routine in Deiner Anwendung.
2. Umsetzen/Parsen in einen String.
3. String wieder als Bytes per TCP senden
4. Bytes wieder in String konvertieren
5. String auseinander nehmen
6. Routine um aus dem String eine Anfrage zu kodieren
7. Umsetzen in JSON
8. Anfrage an PHP (oh grusel)
9. PHP Interpretiert die JSON Anfrage
10. Wieder SQL daraus machen
11. Am Server per TCP anfragen

Und dann das ganze wieder zurück?

Sehen wir mal von meine Abneigung zu PHP ab... Stringanalysen sind immer langsam und Du hast zu viele Konvertierungen.
SQL ist mir schon nicht kompakt genug... Also Übertragungen und Kommandos so knapp wie möglich halten... Besonders wenn Du diese sowieso
per TCP Übertragen willst.

Absender, Kommando, SeekNr, DatenbankID sind bei mir 7 Byte... Wenn man jetzt noch die MTU und ggf. noch für das P2P Protokoll die Daten berücksichtig, ergeben sind 1452 Bytes für Nutzer Daten.
Das ist meine Größe für eine optimale Datenübertragung von mehreren Kommandos...
Aber vielleicht optimiere ich an dieser Stelle auf ein bisschen weit...
Also vergiss den Absatz.

Mavarik
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#2

AW: Client/Server Architektur realisieren - Ideen

  Alt 10. Dez 2014, 10:35
Stringanalysen sind immer langsam und Du hast zu viele Konvertierungen.
SQL ist mir schon nicht kompakt genug...
Ich glaube, Du schraubst am falschen Ende: Ob eine Query 30 oder 100 Zeichen lang ist, sollte nie einen Einfluss auf die Performance haben. Und wenn, dann komprimiere die Kommunikation einfach, wobei das Komprimierung und Dekomprimieren ja auch Zeit kostet...
Und ob ein Parser 0.1 ms oder 1.5ms zum Analysieren des Kommandos benötigt, ist jetzt auch nicht so entscheidend.
Zitat:
Also Übertragungen und Kommandos so knapp wie möglich halten...
Richtig, aber aus einem ganz anderen Grund: Komplexität. Wozu von A, nach B und dann nach C konvertieren und umschrubseln, wenn man es gleich von A->C machen kann.

Deine Überlegungen sind grundsätzlich nicht falsch, aber hier vermutlich deplaziert, wie Du schon festgestellt hast. Bei einer Messdatenerfassung in Echtzeit würde ich dich allerdings konsultieren
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.165 Beiträge
 
Delphi 10.3 Rio
 
#3

AW: Client/Server Architektur realisieren - Ideen

  Alt 10. Dez 2014, 17:46
Deine Überlegungen sind grundsätzlich nicht falsch, aber hier vermutlich deplaziert, wie Du schon festgestellt hast. Bei einer Messdatenerfassung in Echtzeit würde ich dich allerdings konsultieren
Naja... Würden "alle" ein bisschen die Geschwindigkeit im Kopf behalten bräuchten wir nicht immer schnellere PC's

Zugegeben... Manchmal ist es egal ob etwas doppelt so lange braucht. I.d.R. wartet die Software sowieso auf die nächste Eingabe des Benutzers.
Aber wenn eine Aktion schon eine Sekunde dauert - dann fängt es an zu nerven...
Beste Beispiel Du klickst auf einen Button und nix passiert. Nur weil die Routine dahinter keine Ausgabe hat oder den Button nicht sofort Disabled.

Also besonders in den Basis-Routinen sollte man immer ein Augenmerk auf die Performance halten.

Da gehören die Datenbankzugriffe klar mit rein. Daher drehen sich immer Sand-Uhren.

Dummes Beispiel:
Wäre doch schön, wenn ein Programm zum Beispiel bei Aktualisierungen von immer wieder aufgerufenen Listen die ersten 50 Einträger immer aktuell im Speicher hat.
Wenn der Benutzer die Liste aufruft - Schwupdi... Liste da! Rest wird - im Thread - nachgeladen.
- wie gesagt blödes Beispiel - aber ich denke die Idee ist ausbaufähig.

Mavarik
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.666 Beiträge
 
Delphi 12 Athens
 
#4

AW: Client/Server Architektur realisieren - Ideen

  Alt 10. Dez 2014, 19:14
Vorsicht vor Optimierungen
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.165 Beiträge
 
Delphi 10.3 Rio
 
#5

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 16:29
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
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#6

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 16:45
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%.

Geändert von Dejan Vu (11. Dez 2014 um 18:30 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.165 Beiträge
 
Delphi 10.3 Rio
 
#7

AW: Client/Server Architektur realisieren - Ideen

  Alt 12. Dez 2014, 09:33
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
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#8

AW: Client/Server Architektur realisieren - Ideen

  Alt 10. Dez 2014, 21:55
Würden "alle" ein bisschen die Geschwindigkeit im Kopf behalten bräuchten wir nicht immer schnellere PC's
Einerseits.
Andererseits.

Richtig ist, das es seit Jahren eine Vollpfostenmentalität gibt, die auf kompletter Unwissenheit und Borniertheit beruht und mit dazu beiträgt, das Bandbreiten und CPUs immer breiter schneller und tiefergelegt werden müssen.

Nachdenken bzw. ein Bewusstsein für überflüssigen Schnickschnack ist aber wichtig, finde ich.

Aber -mal wieder- Themaabdriftung.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#9

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 00:51
Zum Thema:

Wofür soll der Windows-Dienst mit dem TCP-Server benutzt werden? Der ist mMn völlig überflüssig.

Man nehmen einen MessageQueue-Server seiner Wahl und fragt dort nach Nachrichten. Achtung, nur in einem separaten Thread, denn wenn nichts in der Queue ist, dann dauert diese Abfrage ein Weilchen.

Ist etwas in der Queue, dann bekommt man auch prompt die Antwort, wirft diese dann in der Anwendung in die Runde und wartet auf/holt sich die nächste Nachricht.

Der Rest geht mit der REST-API.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von TheMiller
TheMiller

Registriert seit: 19. Mai 2003
Ort: Gründau
2.480 Beiträge
 
Delphi XE7 Architect
 
#10

AW: Client/Server Architektur realisieren - Ideen

  Alt 11. Dez 2014, 09:13
Moin!

Wofür soll der Windows-Dienst mit dem TCP-Server benutzt werden? Der ist mMn völlig überflüssig.
Ja, da gebe ich dir zwar Recht. Der Server soll aber noch andere Dinge übernehmen, als nur die DB-Anbindung zu verwalten. Ich möchte einen kleinen Realtime-Chat realisieren, eine eigene Datensicherung nur für den Notfall, Benachrichtigungen über den Online-Status der Benutzer etc. Ein weiteres Beispiel: Benutzer 1 - 4 haben das Plugin A offen. Benutzer 1 ändert jetzt einen Eintrag. Der Server soll dann gleich alle anderen Benutzer (2-4) benachrichtigen, dass neue Daten vorliegen, damit dort die Listen neu geladen werden können.

Diese und andere kleine Aufgaben soll der Server bewerkstelligen. Ich denke, es ist nicht verkehrt, einen solchen zu implementieren. Zur Kommunikation bin ich jetzt gedanklich dabei stehengeblieben, ein Record zu versenden. Ist das okay?

Das Record soll mindestens den Timestamp, Absender und die Anfrage (json_string) beinhalten. Mir fällt leider nichts anderes als ein json_string ein. Und da sehe ich ein Problem:

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? Welche Möglichkeit gibt es noch, Objekte/Objectlists über das Netzwerk zu versenden?

Danke!
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:15 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz