Session-Management und applikationsweit verfügbare Objekte

[Eisbär]

Hallo Philipp

Danke für die Anworten, ich werde meine Fragen/Staements aus Deinen beiden letzten Postings hier zusammenfassen.

<Database>
   <var name="login">loginname</var>
   <var name="pwd">pwd</var>
   <data type="array">
      <item type="hash">
         <var name="name">Hasenfratz</var>
         ...
      </item>
      ...
   </data>
</Database>

Diese Struktur lässt sich dann "ziemlich" einfach einlesen und bearbeiten => dies ist eine mögliche Serialisierung des Objektes.

Tatsächlich umfasst meine Applikation auch eine XML-Importschnittstelle, um komplexe Objekte von einem Fremdsystem zu übernehmen.
Nur habe ich grosse Bedenken, wenn ich mir die Module XML-Parser und -DOM anschaue, dass die Lösung bei mehreren dutzend bis hunderten Concurrent-Usern wirklich performant ist. Bei jedem Skriptaufruf der Darstellungsschicht werden mehrere Dutzend Objekte aus rund 10 Objektklassen aufgerufen. Falls ich diese jedesmal durch den XML-Parser duchjagen muss, belaste ich die Performance des Gesamtsystems beträchtlich (Zumindest glaube ich das, wobei Glauben ist nicht Wissen).

Ganz allgemein zielt mein Posting darauf ab, diese persistente Datenspeicherung zwar zu haben, die daraus abgeleiteten Objekte aber zur Laufzeit "global" im Arbeitsspeicher verfügbar zu haben, um bei vielen gleichzeitigen Zugriffen die Performance zu verbessern.

Nun, wenn das auf dem gleichen Computer geschieht (was bei dir ja so ist), sind sie ziemlich schnell (zur Erinnerung: HTTP, FTP, Gopher, ... alles Socketverbindungen). Aber ich kann dir keine Referenzwerte nennen. Was ich jedoch sagen kann, dass z. B. Datenbankschnittstellen (eg. mysql) auch darauf basieren und bekanntlich hat noch "fast" niemand über die Performance gesprochen und wenn überhaupt, dann über die Performance der Datenbank, nicht der Verbindung (zumindest bei grossen Datenbeständen). Also: Über die Performance brauchst du dir glaub ich nicht den Kopf zerbrechen. Wohl eher, ob du es schaffst, dass dein Script wirklich sauber und ohne Fehler arbeitet => Stabilität. Du _musst_ auf jeden Fall sicherstellen, das der Daten-Server _immer_ verfügbar ist und stabil läuft. Das ist keine sehr einfach Aufgabe! - Zudem habe ich etwas bedenken, wenn du nur einen Daten-Server nimmst. Ein Datenserver, mehrere clients? - Das bremst unnötig aus. Eine Möglichkeit wäre es, ca. 10 Datenserver zu preforken (also beim ersten Start gleich 10 Abbilder, die dann jeweis 10 Clients zur selben Zeit bedienen können), oder einfach forken, wenn ein neuer Client Daten braucht (du musst mit fork ja nicht gleich alle Dateien neu einlesen, das OS kopiert den ganzen Interpreter und die Daten für dich).

Die Anforderung nach Stabilität steht bei meiner Lösung auch vor der Forderung nach Performance.
Von der Umsetzung her denke ich jedoch, dass ich bei jedem Skriptaufruf der Darstellungsschicht die Existenz des übergelagerten Prozesses prüfen kann und falls dieser nicht antwortet, wird er neu initalisiert (da die Daten trotz allem persistent gespeichert werden). In diesen (hoffentlich selteren) Fällen wartet der User halt 1-2 Sekunden länger.

Nochmals ein Sorry, was bedeuted fork genau?
Wird dabei ein Prozess mitsammt seinem Speicher "geklont"?
Und noch viel schlimmer, würde das unter WinNT/Win2000 auch funktionieren?
(Eine der Kernanforderungen meiner Lösung ist, dass sie sowohl unter Linux, WinNT/Win2000 und FreeBSD laufähig sein muss).

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.

Grundsätzlich könnte ich mir für diese Applikation durchaus ein SOAP-Interface vorstellen, da dies eh später als weitere Schnittstelle für externe Systeme angedacht ist. Zum Datenaustauch von Objekten innerhalb der Applikation möchte ich aber davon Abstand nehmen.

Direkt nein. Indirekt über die genannte Serialisierung. SOAP und RPC verwenden z. B. Serializer. Du könntest auch ein eigenes Modul schreiben, was eine Datenstruktur in einen XML-Stream abbildet.

Soweit ich das verstehe, ist SOAP und RPC vergleichbar zu dem, was wir uns oben zusammengedacht haben: Serialisierung der Objekte und Datenaustausch über eine Socketverbindung. Der einzige Unterschied ist, das dies standardisiert erfolgt.
Somit verringert es mein Performanceproblem eher nicht.

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.

So was in der Art könnte ich mir vorstellen. Für die oben genannte XML-Schnittstelle habe ich mir schon ein XPath-ähnliches Interface geschrieben, werde nun aber auf das Modul XPath wechseln. Damit sollte sich so was grundsätzlich lösen lassen, aber wie gesagt, dazu muss jedes einzelne Objekt bei jedem Skriptaufruf nochmals durch den XML-Parser ... :-(

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...

Danke für Deine reflektierenden Antworten, ich werde wohl eher bei der persistenten Datenspeicherung in einer Datenbank bleiben und die Objekte bei jedem Skriptaufruf neu aus der Datenbank generieren. Tatsächlich kann ich die Objektklassen so ausgestalten, dass der DB-Zugriff nur auf konkrete Anforderung erfolgt.

Dies wird zumindest vorläufig ausreichen. Später könnten aber Anforderungen folgen, wo ich enteder einen fetten Server hinstellen muss oder das Ganze gescheit in einer Applicationserver-Umgebung (WebObject, ASP oder andere) neu programmiere.

Danke nochmals für Dein konstruktives Feedback und gute Nacht ;-)

Grüsse
Eisbär