Performant: Socket oder Cashing

Hi zusammen,
ich möchte die Lage kurz schildern. Ich erstelle momentan eine Schnittstelle die zwei Programme parallel managen soll. Dabei kommt es zwischen diesen beiden Progammen zu einem Datenaustausch über Sockets.

Meine Frage nun: Wenn einer dieser Programme(bsp: Programm mit der anderen(Pro. Y) kommunizieren möchte, ist es besser die komplete Palette an Daten direkt zu übertragen und das andere Programm(prog. Y) diese Daten speichert. So kann das Programm Y die Daten bei Bedarf aus seiner map entnehmen. Oder ist es effizienter, dass Prog. Y für sich aktuell benötigte Daten, über die vorhandene Socketverbindung, einzeln von Prog. X anzufordert? Also eher Caching oder doch lieber Datenaustausch?

Es ist etwas umständlich beschrieben sorry.

PS: Wenn ihr noch Quellen bzw Referenzen zu eueren Beiträgen angibt, wäre ich dankbar.

Michael E.

Werden denn alle verfügbaren Daten von Programm Y benötigt oder nur ein Teil? Wie groß ist der Teil? Über welche Gesamtgröße reden wir?

Es kommt ganz darauf an. Mal kommt es vor, dass Program Y die meisten Daten benötigt mal keine. Die Größenordung erstreckt sich ca. maximal 400 map Einträgen.

volkard

Vorher alles schicken: Macht beim Empfänger eine merkliche Startverzögerung. Aber es kann besser gepackt werden und der COde ist auch einfach.

Alles erst bei Bedarf anfordern: Keine Startverzögerung aber lauter Mini-Verzögerungen während des Laufs.

Alles erst bei Bedarf anfordern UND cachen: Keine Startverzögerung aber lauter Mini-Verzögerungen während des Laufs, die verschwinden aber mit der Zeit.

Alles bei Bedarf anfordern UND cachen ABER leere Bandbreite nutzen zum wahlosen Füllen: Keine Startverzögerung aber lauter Mini-Verzögerungen während des Laufs. Die Mini-Verzögerungen halten aber kaum länger als die Startverzögerung beim ersten Verfahren.

Alles bei Bedarf anfordern UND cachen ABER leere Bandbreite nutzen zur Vorwegnahme mit Heuristik, was als nächstem Anliegt (z.B. geographische Nachbarschaft auf der Landkarte): Keine Startverzögerung und nur Mini-Verzögerungen während des Laufs, wenn die Heuristik mal versagt.

Alles bei Bedarf anfordern UND cachen ABER leere Bandbreite nutzen zur Vorwegnahme mit Heuristik, was als nächstem Anliegt, ansonsten wahhlos Füllen: Keine Startverzögerung und nur Mini-Verzögerungen während des Laufs, wenn die Heuristik mal versagt. Die Mini-Verzögerungen halten aber kaum länger als die Startverzögerung beim ersten Verfahren.

Ach, man müßte die Datenlage und das Userverhalten schon sehr genau kennen, um da was Schlaues antworten zu können, fürchte ich.

volkard

Beobachter01 schrieb:

Es kommt ganz darauf an. Mal kommt es vor, dass Program Y die meisten Daten benötigt mal keine. Die Größenordung erstreckt sich ca. maximal 400 map Einträgen.

Also 400 Einträge mal zwei Wörter zu je 20 Bytes, sind 16k, sind 11 Ethernetpakete, ist genau gar nicht spürbar. Vorher alles schicken.