Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
7 Antworten auf „Caching Mechanismus“
Verworfen werden bewußt keine gecachten Daten.
Einige Plugins (wie zum Beispiel vermutlich die genannten) bereiten aber das verwendete Datenmodell entsprechend auf, da in dem von der Datenverteilerkonfiguration vorgegeben Modell insbesondere Rückreferenzen nicht enthalten sind.
Das ist aber aus meiner Sicht kein Problem des Cachings an sich. Wenn hier eine Optimierung erfolgen müsste, dann höchstens innerhalb der Plugins selbst. Beispielsweise wäre denkbar, einen Cache zu implementieren, der erst dynamisch nach Bedarf aufgebaut wird, womit sich das Startverhalten verbessern würde, aber eventuell stellenweise zur Laufzeit Verzögerungen auftreten könnten bis der Cache den Erfordernissen gemäß gefüllt ist. Hier einen Kompromiss zu finden ist nicht einfach und die Frage welche Varianten besser sind lassen sich ad hoc nicht beantworten.
Das bedeutet, dass die Teilanforderung zum Rahmenwerk abgeschlossen ist: das Rahmenwerk setzt die Anforderung korrekt um.
Die Teilanforderung zu den Plug-ins ist noch offen. Insbesondere bei den beiden genannten ist zu prüfen, ob Optimierungsmöglichkeiten bestehen.
Hierzu übrigens die Präzisierung, dass der beobachtete Neuaufbau der Caches vermutlich auftritt, wenn zwischendurch ein anderer Datenverteiler genutzt wurde. Hier wäre zu prüfen, ob bei den beiden Plug-ins die Caches in Abhängigkeit der IP (wie beim Rahmenwerk) gespeichert werden oder nur einer allgemein. Denn bei Verwendung des gleichen Datenverteilers funktionieren die Caches einwandfrei.
Es gibt nur einen Cache. Beim Verlust der Datenverteilerverbindung wird alles ungültig gemacht, es sit ja auch nicht sichergestellt, dass es sich bei gleicher IP-Adresse und Port nach einer Neuanmeldung tatsächlich um den gleichen Datenverteiler handelt und dass die Konfiguration inhaltlich noch der „alten“ entspricht.
Ich sehe in ihrer Nachfrage eventuell auch noch ein Mißverständis: Die Caches der Plugins werden nur im RAM gehalten und nicht irgendwo persistiert, wie das die lokal abgelegte Konfigurationsdatei tut!
Das kann aber nicht sein: wenn ich die drei Netz-Caches „erstmalig“ aufrufe, muss ich längere Zeit warten. Beende ich das Rahmenwerk und starte mit dem gleichen DaV neu, laufen die drei Caches in wenigen Sekunden durch und man kann arbeiten. Die müssen also irgendwo physikalisch gespeichert sein – oder ich verstehe es nicht.
Das liegt daran, dass die „internen Caches“ nicht den Aufwand bedeuten und beim zweiten Start auf den dann gespeicherten lokalen Konfigurationscache zurückgreifen (intern über die Datenverteiler-Applikationsfunktionen).
Ich sehe gerade, dass ich seither einem Irrtum aufgesessen bin. Ich dachte, die Cache-Datei gäbe es je DaV-Verbindung. Aber sie gibt es wirklich nur pro Nutzer. Wieder etwas dazu gelernt….
Welche Plug-ins nutzen diese speziellen Caching-Funktionalitäten? Welche Rückreferenzen müssen dabei verwaltet werden?
Wir haben immer (noch) die Engstellenverwaltung und die RDS-Meldungseingabe im Verdacht, das Caching nur suboptimal einzusetzen und zu oft oder zu viel den vorhandenen Cache zu verwerfen, was sich negativ auf die Startzeiten der Plug-ins auswirkt.
Verworfen werden bewußt keine gecachten Daten.
Einige Plugins (wie zum Beispiel vermutlich die genannten) bereiten aber das verwendete Datenmodell entsprechend auf, da in dem von der Datenverteilerkonfiguration vorgegeben Modell insbesondere Rückreferenzen nicht enthalten sind.
Das ist aber aus meiner Sicht kein Problem des Cachings an sich. Wenn hier eine Optimierung erfolgen müsste, dann höchstens innerhalb der Plugins selbst. Beispielsweise wäre denkbar, einen Cache zu implementieren, der erst dynamisch nach Bedarf aufgebaut wird, womit sich das Startverhalten verbessern würde, aber eventuell stellenweise zur Laufzeit Verzögerungen auftreten könnten bis der Cache den Erfordernissen gemäß gefüllt ist. Hier einen Kompromiss zu finden ist nicht einfach und die Frage welche Varianten besser sind lassen sich ad hoc nicht beantworten.
Das bedeutet, dass die Teilanforderung zum Rahmenwerk abgeschlossen ist: das Rahmenwerk setzt die Anforderung korrekt um.
Die Teilanforderung zu den Plug-ins ist noch offen. Insbesondere bei den beiden genannten ist zu prüfen, ob Optimierungsmöglichkeiten bestehen.
Hierzu übrigens die Präzisierung, dass der beobachtete Neuaufbau der Caches vermutlich auftritt, wenn zwischendurch ein anderer Datenverteiler genutzt wurde. Hier wäre zu prüfen, ob bei den beiden Plug-ins die Caches in Abhängigkeit der IP (wie beim Rahmenwerk) gespeichert werden oder nur einer allgemein. Denn bei Verwendung des gleichen Datenverteilers funktionieren die Caches einwandfrei.
Es gibt nur einen Cache. Beim Verlust der Datenverteilerverbindung wird alles ungültig gemacht, es sit ja auch nicht sichergestellt, dass es sich bei gleicher IP-Adresse und Port nach einer Neuanmeldung tatsächlich um den gleichen Datenverteiler handelt und dass die Konfiguration inhaltlich noch der „alten“ entspricht.
Ich sehe in ihrer Nachfrage eventuell auch noch ein Mißverständis: Die Caches der Plugins werden nur im RAM gehalten und nicht irgendwo persistiert, wie das die lokal abgelegte Konfigurationsdatei tut!
Das kann aber nicht sein: wenn ich die drei Netz-Caches „erstmalig“ aufrufe, muss ich längere Zeit warten. Beende ich das Rahmenwerk und starte mit dem gleichen DaV neu, laufen die drei Caches in wenigen Sekunden durch und man kann arbeiten. Die müssen also irgendwo physikalisch gespeichert sein – oder ich verstehe es nicht.
Das liegt daran, dass die „internen Caches“ nicht den Aufwand bedeuten und beim zweiten Start auf den dann gespeicherten lokalen Konfigurationscache zurückgreifen (intern über die Datenverteiler-Applikationsfunktionen).
Ich sehe gerade, dass ich seither einem Irrtum aufgesessen bin. Ich dachte, die Cache-Datei gäbe es je DaV-Verbindung. Aber sie gibt es wirklich nur pro Nutzer. Wieder etwas dazu gelernt….
Welche Plug-ins nutzen diese speziellen Caching-Funktionalitäten? Welche Rückreferenzen müssen dabei verwaltet werden?
Wir haben immer (noch) die Engstellenverwaltung und die RDS-Meldungseingabe im Verdacht, das Caching nur suboptimal einzusetzen und zu oft oder zu viel den vorhandenen Cache zu verwerfen, was sich negativ auf die Startzeiten der Plug-ins auswirkt.