Re: Stresstest fuer syslog-Server?

On Fri, Jul 15, 2005 at 09:20:21PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Fri, Jul 15, 2005 at 05:34:34PM +0200, Oliver Fromme wrote:
> > > Die für den Betrieb notwendigen Informationen bekommt man
> > > auch, ohne jeden einzelnen angebotenen Artikel loggen zu
> > > müssen.
> >
> > Ja, für reine Summergeschichten schon, aber bisweilen geht es
> > auch darum was mit bestimtme Artikeln passiert ist.
>
> Das fällt dann unter »vorübergehendes Debuggen«.

Neh - das ist Qualitätskontrolle - sowas ist ein permanenter Process.

> Da muß man das Logging natürlich hochschrauben.
>
> > > Dazu genügen die Summen-Informationen, die der innd liefert
> > > (und die man natürlich nach wie vor loggen sollte).
> >
> > Als ich das letzte mal damit zu tun hatte war innd zu überhaupt nichts
> > mehr zu gebrauchen.
> > Zum einen hat der damals noch einzelne Files gespeichert
>
> Dann muß das aber schon _sehr_ lange her sein. :-)

Naja - sind schon einige Jahre.

> INN unterstützt schon seit etlichen Jahren eine Reihe von
> Storage-Formaten, darunter Cycle-Buffer, die für Full-Feed-
> Server ein »Muß« sind.
>
> Wobei es für reine Transit-Server ohnehin bessere Software
> gibt als den INN. Und die scheren sich in der Regel noch

Ein Transit Server hat keine Haltezeit von einer Woche.
Innd war damals halt für nichts zu gebrauchen.
Aber ja - es gibt bessere Software.

> weniger um das Loggen einzelner angebotener Artikel, weil
> das völlig uninteressant ist -- Zum Anfertigen aussage-
> kräftiger Statistiken ist das nämlich nicht erforderlich.

Du hast scheinbar andere Anforderungen an Statistiken.
Beim Betrieb eines reinen Transit-Server muß man schon wissen, ob die
anderes Peers in der Lage wären einen Ausfall einer der aktuell
bevorzugten zu ersetzen.
Und man muß sogar wissen welcher Peer dann in Frage kommt, man reded
da immerhin bei einem Full-Feed von etlichen hundert GB/Tag, die einen
ganz gewaltigen Lastwechsel auf Leitungen verursachen, blos weil einer
der bevorzugten Peers gerade mal eine Sekunde Delayzuwachs hat.
Da geht es um ziemlich hohe Geldbeträge für Bandbreitenverfügbarkeit
und auch die Abschätzung, ob kleinere Peers einen potentiellen Nutzen
bringen, oder nur Leistungen in Anspruch nehmen.
Und zu guter letzt geht es auch darum die Sicherheit zu haben, das man
trotz etlicher Peers nicht doch bei einzelnen Gruppen von einem
einzigen abhängig ist.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message