Re: OpenBSD

From: Jens Rehsack <rehsack(at)liwing.de>
Date: Sun, 26 Oct 2003 15:50:28 +0000

Bernd Walter wrote:
> On Sun, Oct 26, 2003 at 02:49:47PM +0000, Jens Rehsack wrote:
>>Bernd Walter wrote:
>>>Wenn mir Performance wichtig wäre, dann würde ich weder MySQL noch
>>>Apache nehmen.
>>
>>Hm, das mit dem MySQL sehe ich ja durchaus ein. Nach dem iX-Test (der
>>inzwischen zwar schon etwas zurück liegt), ist beispielsweise
>>PostgreSQL einiges fixer.
>>Aber der Apache, insbesondere der Apache2 sollen doch eigendlich
>>recht fix sein.
>>
>>Hast Du hier Empfehlungen?
>
> thttpd - natürlich kommt der Mangels Features nicht in allen Fällen in
> Frage, aber man kann auch schnell dynamische Seiten direkt im Source
> einbauen - ist eine sehr übersichtliche Software.

Mal anschauen. Vielleicht passt er ja ganz gut.

>>>Auch die Nutzungsart hat mehr Einfluß auf die Performance.
>>>Ich habe Datenbankprogrammierungen gesehen, da könnte man meinen das
>>>der dahinterliegende Server per Definition groß genug zu sein hat.
>>
>>Das ist dann sowohl eine Frage der Applikation (optimiert auf ...)
>>als auch des Tunings derselben.
>
> Naja - So manche Designs würde ich weniger als tuning, sondern neu
> machen einstufen.

Das meinte ich nicht. Es gibt ja schon Unterschiede bei z.B.
DB2 und Oracle, speziell wenn man Peaks und mittlere Zeit
zur Bearbeitung von Anfragen vergleicht. DB2 lässt sich nur
schwer zum raschen Beantworten tunen, Oracle ab einer gewissen
Datenbankgröße nur schwer auf gute Durchschnittswerte.

Wie Du schon sagst, man kann es nicht allen recht machen.

> Wenn einer ein schlechtes Design vorsetzt und dann meckert, daß es
> unter dem OS foo schneller läuft, dann sollte man demjenigen das um die
> Ohren hauen.

Na ja, es gibt immer Optimierungen in die eine oder andere
Richtung seitens des Systems. Da kann man dann entwder dran
vorbei programmieren (wie z.B. im Falle von malloc()), oder
auch nicht, wenn z.B. viele kleine Datensätze geschrieben
werden, die System a gut zwischen puffert, System b aber
nicht. Klar kann man einen Quasi-Cache auf Applikationsebene
bauen, aber dann macht ein Systemwechsel u.U. Sinn, wenn
ein Applikationsänderung aus welchen Gründen auch immer
nicht in Frage kommt.

>>Also Tuning. Ein bekanntes Problem von FreeBSD ist allerdings z.B.,
>>dass das allokieren von vielen, kleinen Speicherblöcken recht lange
>>dauert. Perl hat deswegen z.B. ein eigenes malloc().
>
> Yepp - und es ist auch schon oft bewiesen worden, daß die Ursache an
> der eigenwilligen Nutzung von Perl liegt.

Mag ja schon sein, es gibt allerdings genügend Projekte,
die mit Perl gemacht wurden, z.B. weil es mit der Analyse
von irgendwelchen Files angefangen hat und der Rest drum(k)rum
gewachsen ist.
Ist aber auch egal, weil Perl seine Schwachstelle ja kennt
und eine hauseigene Lösung mitbringt.

> Du kannst es nicht jedem recht machen - so eine Systemfunktion ist
> immer ein ausbalancieren zwischen den üblichen Nutzungen.

Schon klar. Das ist es ja, was ich meine. Manchmal ist halt
die typische Nutzung durch die Anwender von Systemen von
System zu System verschieden.

> Abgesehen davon bin ich absolut kein perl Fan.

Ich auch nicht, aber bestimmte Sachen gehen einfach
genial damit. Also sehe ich da mal über persönliche
Differenzen hinweg. :-)

>>Ich weiss ja nicht, wie es bei den anderen BSD's ist, aber sollte
>>eine Applikation genau daran in der Performance scheitern, kann es
>>für den Admin einfacher sein, das System zu tauschen.
>
> Das ist keineswegs einfacher - man hat sich ja im Vorfeld aus gutem
> Grund zu einem System entschieden.

Beispielsweise, weil man es kannte. Stellt sich jetzt das
System als Bottleneck heraus, und ich kenne ein System, bei
dem dies nicht so ist, macht es durchaus Sinn, zu tauschen
(zu migrieren).

> Wenn man es jetzt austauscht, dann ändern sich andere Parameter.
> Man sollte sich *immer* mit der Ursache auseinandersetzen - evtl ist
> die ja Hausgemacht.

Natürlich.

> Außerdem ist die OS Entwicklung auf derartige Rückmeldungen angewiesen,
> sonst wird sich auch keiner der Sache annehmen.
> Systeme Tauschen bis gut werte ich als rumbasteln.

Na ja, das malloc() Problem ist bekannt, wird aber wahrscheinlich
aus o.g. Gründen nicht abgeändert werden.

Gruß,
Jens

To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 26 Oct 2003 - 16:51:03 CET

search this site