[Postfixbuch-users] Test-Spool erzeugen

[Alexander Stoll]

Stefan Förster schrieb:
> Hallo Welt,
> 
> nachdem wir mittlerweile mit der Evaluation der Funktionalität unseres
> angestrebten neuen Setups fertig sind (Backend-Clustering, Patches
> gegen amavisd-new & Perl, Change-Management etc.) würden wir gerne
> harte Zahlen zur Performance sammeln - Anazahl der
> content_filter-Prozesse, Einstellungen an den Content-Filtern, den
> DB-Backends etc.
Ok

> Meine erste Idee dazu war eigentlich recht einfach: Man versetzt die
> gesamte Testumgebung in einen definierten Zustand (leere DNS-Caches,
> leere FS-Caches), stoppt Postfix, schiebt ihm einen sehr großen Spool
> unter (das muß gar nicht mal in pickup sein, sondern von mir aus auch
> gleich in Incoming oder gar Active) und startet Postfix wieder.
> Während sich das System dann durch ein paar 100k Nachrichten knabbert,
> geht man auf die Dachterasse... ich schweife ab.
Das ist doch gar nicht der "Normalzustand", willst Du die "Anlauframpe" bei 
der Inbetriebnahme testen oder den "normalen" Dauerbetrieb?

> Das Problem mit der Idee ist nun ein unheimlich triviales: Wie erzeuge
> ich diesen Spool? Idealerweise würde ich einfach ein laufendes Postfix
> dazu bewegen, seinen Spool doppelt anzulegen - dann hätte ich nach ein
> paar Tagen genau die Art realer Daten, die ich brauche. Blöderweise
> scheint das nicht möglich zu sein.
> 
> Natürlich kann ich einfach eine Woche lang mit BCC arbeiten, die
> Nachrichten dann auslesen, die Header modifizieren und dann wieder
> lokal injecten - mit Realität hat das aber nicht viel zu tun, genauso
> wenig wie das Einliefern der Nachrichten von Test-Clients aus.
Wozu das? "Reale Daten" sind so eine Sache, Stichwort Datenschutz, ich hätte 
da größte Bedenken fremde Daten der Benutzer zu sowas heranzuziehen - Du 
schreibst ja auch nicht genau in was für einer Umgebung dies ablaufen soll.
Um ein paar harte Eckdaten des Setup zu ermitteln, reichen doch synthetische 
Daten völlig aus, verschiedene Größen, Testdatentypen, sinnvolle Startwerte 
ermittelt man einfach mittels Auswertung der Logs des Produktivsystems.
Wenn Du ein Patentrezept erwartest, es existiert nicht. Die Daten, die ein 
Mailsystem zu verarbeiten hat, ändern sich idR doch täglich und es reduziert 
sich immer auf eine quantitative Betrachtung und das neue System wird eh auf 
Wachstum ausgelegt sein, da reicht es doch zu validieren, dass genug "Luft 
nach oben" existiert.

> Wie geht man sowas an?
Hmm, erwartest Du ein funktionierendes "Drop In Replacement"? Trotz allem 
angesprochenem Testen, fallen mir immer noch zu viele Gründe ein, warum einem 
sowas doch noch um die Ohren fliegen kann. Ganz klassisch über Parallelbetrieb 
und häppchenweiser Lasterhöhung, da sieht man dann idR das Unheil schon kommen 
und kann ggf. rechtzeitig Gegenmaßnahmen einleiten. Alles spezifischere liegt 
eigentlich schon sehr weit außerhalb dessen, was eine Mailingliste leisten 
kann, im Bereich der bezahlten Consulting Leistung, ich gehe hier einfach mal 
von einer entsprechend komplexen Umgebung mit hohem Volumen aus.

Und mal ehrlich, Du scheinst das nicht erst seit gestern zu machen und wenn 
man so weit gekommen ist, ist der letzte Schritt keine echte Hürde mehr...
Die Doku zum Performance Tuning und Handhabung von smtp-sink /smtp-source 
liefern doch gute Startpunkte.

Wenn Du dann Sachen fragst wie: "Tool XY generiert mir nicht eine Testmail mit 
den Eigenschaften Z, wie macht Ihr das?" dann sind wir wieder im Bereich, was 
eine Mailingliste leisten kann.

Gruß, AS

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 3237 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20080621/c9290951/attachment.bin>