[Postfixbuch-users] Effektivität von smtpd_proxy_options=speed_adjust

[Stefan Förster]

* Peer Heinlein <p.heinlein at heinlein-support.de>:
> Am Sonntag, 6. Dezember 2009 schrieb Stefan Förster:
[smtpd_proxy_options = speed_adjust]
> Wenn Du jetzt die Warte-Verbindungen reduziert heißt das nicht, daß Du
> mehr schaffst. Die CPU wird quasi genauso viel zu tun haben, wie vorher
> auch.

Daß ein einzelner Filter-Prozess mit diesem Feature nicht plötzlich
mehr Mails scannen können wird, war mir schon irgendwie klar ;-)

Trotzdem siehst Du da IMHO nur einen Teil des ganzen Bildes.

> Ergo: Dieses Feature hilft, wenn RAM der Flaschenhals war/ist. Dieses
> Feature hilft nicht/kaum, wenn CPU oder I/O der Flaschenhals ist.

Wenn man nur gut angebundene Clients hat, die die Mails schnell über
die Leitung bringen, dann hast Du recht, da sind CPU bzw. I/O der
Flaschenhals.

In allen anderen Fällen aber hat man aber IMHO die folgenden Vorteile:

1. Es reduziert das DoS-Risiko. Wie schieße ich denn heute einen
Server ab, von dem ich weiß, das er im pre-queue-Modus filtert? Ich
suche mir 5 Clients die nicht irgendwo geblacklistet sind, mache von
jedem aus 5 Verbindungen auf und übertrage da jeweils sehr langsam
eine Mail. Aus die Maus, wenn die Gegenseite <= 25 Filter-Prozesse am
Start hat (oder eine Konfiguration, die nur je eine Verbindung pro
Client zulässt, wie realistisch das auch sein mag).

2. Es bewahrt mich davor, die Anzahl der Filterprozesse
überdimensionieren zu müssen: Ich würde mein letztes Hemd darauf
verwetten, daß nur ein Bruchteil der Leute, die mit mehr als 20
Filter-Prozessen fahren, schonmal ausprobiert haben, was passiert,
wenn diese Filter wirklich alle auf einmal aktiv werden müssen - da
würde es garantiert einiges an Heulen und Zähneklappern geben, à la
"aber im Test mit smtp-source hat er doch auch nicht geswappt....!"
Mit dem Patch kann ich mir die 40 amavisd-new-Prozesse getrost
schenken.

3. Am wichtigsten: Man kann mit dem Patch immer mindestens genauso
viele Mails filtern wie ohne - kommen aber Clients dazu, die lange
brauchen, um eine Mail zu übermitteln, dann kann ich mit der
Erweiterung _immer_ _mehr_ Mails verarbeiten als ohne - weil das 4kB
große Mailinglisten-Posting eben schneller einen freien Filter-Slot
bekommt, den ohne speed_adjust die 20MB PPT-Präsentation oder ein
Zombie in Beschlag hat.

Und wenn man sich den letzten Punkt ansieht, dann irsst Du hier
teilweise- man schafft mit gleicher Prozess-Zahl eine bessere
Auslastung der eigenen Resourcen - und damit dann eben doch mehr Mails
;-)

Ich sehe das Feature in der selben Ecke wie den Stress-Modus oder
postscreen(8): Möglichst effizientes Haushalten mit den eigenen
Resourcen im Angesicht von Botnetzen. Nur zu sagen "Das spart RAM" ist
ein bißchen kurzsichtig.


Ciao
Stefan

P.S: Interessanterweise war einer der "early adaptors" auch Mark
Martinec - und genau der hat bisher immer davon abgeraten, amavisd-new
im pre-queue-Modus zu betreiben.
-- 
Stefan Förster     http://www.incertum.net/     Public Key: 0xBBE2A9E9
"Eins mal vorweg: Frauen dürfen regelmäßig sowenig tragen wie sie
wollen, da es seltener vorkommt, dass sie sowenig tragen wie ich
will."
    -- L.K.