Philipp Hasenfratz: Session-Management und applikationsweit verfügbare Objekte

Beitrag lesen

Halihallo Eisbär

Hm. Bin glaub ich etwas über das Ziel hinausgeschossen. SOAP und RPC sind IHO etwas langsam, da du ja eben genau die Performance damit verbessern willst. Zudem ist die Verwendung von SOAP und RPC eigentlich auch anders.
Du könntest dir natürlich Serialisierungsmöglichkeiten den Modulen entnehmen (zum Serialisieren wäre auch ein Blick in den Source von Data::Dumper nicht schlecht). Aber diese Module sind nich für TimeResistant-Programme gedacht, sondern eben dafür, dass die Objekt-Struktur auf über mehrere Scriptzugriffe hinaus gleich bleibt. Fakt ist, dass selber geschriebene SOAP-Module dennoch bei jedem Zugriff die Daten einlesen müssten => sprich, die Daten werden nicht im Speicher aufgewahrt, sondern auf der langsamen Platte.

Also, zweiter Versuch:
Einmaliges Serialisieren in eine XML-Struktur (Standard...), die erzeugte XML::DOM-Instanz (oder willst du einen anderen Parser verwenden?) im Speicher halten und dann ein Socket-Interface aufbauen, womit du mit einfachen Befehlen durch diese Struktur "browsen" kannst (kannst ja ein eigenes XPath-Interface basteln ;)). Wenn du STRING, ARRAY und HASH verwendest, dürfte das nicht allzuschwer sein.

GET /Node1/test/[2]/{'test'}

<< RESULT successful

oder

GET /Node1/test/[1]

<< RESULT b

GET /Node1/test/[0]

<< RESULT a

<struct name="Node1" type="hash">
   <struct name="test" type="array">
      <struct name="Node2" type="array">
         <var value="a" />
         <var value="b" />
         <struct name="Node3" type="hash">
            <var name="test" value="successful">
         </struct>
      </struct>
   </struct>
</struct>

oder so... Noch etwas kompliziert, aber das kann man wohl vereinfachen.

Also irgendwie scheint mir das alles etwas zu Zeitaufwändig zu sein, nur um die Performance etwas zu verbessern. Müssten denn deine 50 Programme soviele Daten aus einer DB einlesen? - Könnte man das nicht etwas beschränken (z. B. nur Daten laden, wenn sie benötigt werden)? - Zudem glaube ich schon, dass die Performance einer reinen DB-Lösung nicht so schlecht wäre... Kannst du vielleicht noch etwas mehr über die Programme sagen? - Ich bin sicher, dass es noch eine bessere Lösung gibt.

Viele Grüsse

Philipp