Re: OpenBSD

Bernd Walter wrote:
> On Sun, Oct 26, 2003 at 06:42:37PM +0000, Jens Rehsack wrote:
>
> Mit poll meinte ich auch die ganze Familie - poll benutzt auf
> einem FreeBSD keiner mehr, wenn es um Performance geht, ebensowenig
> select.
> Die Wahl fällt heutzutage auf kevent.

Gut zu wissen.

> PHP kann Sablot auch nicht schneller aufrufen, als ein C/C++
> Programm direkt.

Meine ich doch. Beispielsweise könnte man sich das ständige
Neuparsen der XSLT's sparen. Einmal als Handle angelegt,
immer verfügbar. Bei XSLT-Dateien um die 150k bringt das
sicher einiges.

>>Die aktuelle Neuerung ist die, die Du jetzt
>>angesprochen hast: statische HTML-Seiten. Die
>>einmal gerenderten Seiten liegen jetzt in einem
>>lokalen Cache und werden direkt ausgeliefert.
>
> Ganz gemeine Sache - thttpd arbeitet mit sendfile, weswegen bei
> gut selektierter Hardware ein File schneller geschickt werden kann,
> wenn es aus einem im Cache liegenden File kommt, als wenn es aus
> dem Hauptspeicher der Applikation kommt.

Ok, das ließe sich aber auch sicher in's PHP implementieren.
So nach dem Motto:

--- BEGIN
if( !is_cached( $obj->identifier() ) )
{
   $obj->calc_output();
   $obj->save_cache();
}

$fn = $obj->get_cache_filename();
sendfile( $fn );
-- END

>>Aber auch da ist PHP selbst nicht die Bremse.
>
> Eben doch.

Vergiss nicht, dass da Applikationlogik dahinter steht.
Die meiste Laufzeit geht in drunter liegenden C/C++
Bibliotheken drauf. In PHP steckt "nur" ein dynamisches
Objektmodell.

>>Klar, direktes C++ würde vermutlich aus einigen
>>Komponenten 40%-60% mehr rausholen, per FastCGI
>>angebunden würde auch einiges an Initialisierungs-
>>aufwand wegfallen, aber der Programmieraufwand
>>wäre mit ca. 18 MM doch etwas hoch für den
>>zu erwartenden Mehrwert.
>
> Kommt auf die Komplexität der Anwendung an.

Leider. Und die ist recht hoch.

>>Da macht es doch eher Sinn, erstmal zu tunen,
>>was man hat, und parallel dazu auf C++ umzustellen.
>
> Nein - das macht keinen Sinn an 1-2% rumzuwerkeln, wenn sehr viel mehr
> wartet.

Wir spielen nicht mit 1-2%, sondern mit 10-20%.
Meine letzte Tuningmaßnahme hat sogar 60% mehr Leistung
gebracht. Das war eine kleine Umstellung des verwendeten
Algorithmus. Die Sprache, in der programmiert wird, ist
gar nicht mehr so wichtig, das sind nur Konstanten.
Kritisch ist die Komplexität der Implementation, deren
Wartbarkeit und die Erweiterbarkeit.

> Du kannst eher anfangen Teilsysteme zu portieren - wenn das Kind schon
> im Brunnen gefallen ist.

So hatte ich es auch gedacht :-)

>>>Wenn du Performance willst, dann empfehle ich immer noch thttpd mit
>>>statischen Seiten oder eingebautem C-Code.
>>
>>Dasselbe könnte man zu Java-Servlets sagen. Geben
>>tuts die trotzdem. Warum: Weil manchmal ein
>>früheres Ergebnis deutlich mehr wert ist, als
>>ein super schnelles System. Ich kann in der
>>Folgeentwicklung immernoch kritsche Komponenten
>>per Native-Interface auslagen.
>
> Ein Bekannter ist Wartungsprogrammierer und muss das geradebiegen, was
> das Marketing so auf die schnelle eingekauft hat.
> In der Regel ist das Neuprogrammierung.
> Dumm ist nur, daß es nicht schneller programmiert wurde, sondern nur
> mit weniger Know-How.
> Biller durch die Know-How Einsparung ist es aber im Endergebniss auch
> nicht, weil das Know-How in der Wartung letzlich doch nötig ist.

Ein Bekannter von mir ist Business-Analyst. Der ist für
solche Taten verantwortlich, die Dein Bekannter ausbügeln
muss :-)

>>>thttpd hat ebenfalls nichts von SMP, kann aber richtig eingesetzt
>>
>>Schade, eigendlich.
>
> Warum?
> SMP ist erst mal eine Bremse, genauso Threads.

Weil der Kommunikationsaufwand zwischen Threads geringer ist, als
der zwischen Prozessen. Selbst wenn immer ein Thread eine Aufgabe
bearbeitet, ist das letztendlich effizienter, als eine Aufgabe
pro Prozess.

> Der Verlust muss erst mal wieder kompensiert werden.

Wird er auch, wenn der Programmierer Ahnung davon hat :-)
Ich weiss, Unix' Hammer ist fork(), aber ich komme letztendlich
aus der OS/2-Welt, und da waren Threads gar nicht so schlecht.
Vor allem gab's sie schon immer und daher hatte ich die Gelegenheit,
das von Anfang an so zu lernen :-)

Unter Unix ist das inzwischen auch richtig gut. Thread-Pool,
Task -> Thread Zuordnung, eine Aufgabe pro Task, fertig ist der Lack.
Kommunizieren kannst Du über pthread_mutex statt sysvsem, ist auch
etwas fixer.

> Und ein Webserver soll erst mal TCP Requests abhandeln - problemlos
> auf mehrere Maschinen/Prozesse verteilbar.

Außer, er kann nicht mehr nur statische Seiten liefern. Dann kommt
es darauf an, wo die Abarbeitung erfolgt. Im Webserver (Modul), dann
ist Multiprozess nicht wirklich erste Wahl. Machst Du's extern, z.B.
via FastCGI, dann kann der Webserver natürlich soviele Prozesse haben,
wie er will.

Prozessinterne Kommunikation ist immer schneller als Interprozess-
kommunikation. Wenn allein die Konfiguration lesen und in
Datenstrukturen umsetzen knapp 5% der Laufzeit eines Durchlaufs
ausmacht, ist es besser den einfach wegzulassen, wenn man z.B.
das nur 1x beim Prozessstart erledigt und jeder Thread lesend
darauf zugreift.

> Die dahinterliegende Datenbank ist das, was man nicht mehr so einfach
> verteilen kann.

Kommt auch immer drauf an. Typischerweise sind bei Onlineshops
ein sehr hoher Prozentsatz rein lesende Zugriffe. Da reicht ein
Datenbakserver mit Lesezugriff völlig hin, den man beliebig
verteilen (theoretisch) kann.

> Wenn du tatsächlich eine 2 CPU Maschine im Frontend hast, dann startest
> du halt zwei Instanzen und das wars - ohne Thread Overhead.

Aber mit IPC Overhead - der mich im Zweifel teurer kommt.

>>So ist das eben. Als wir damit angefangen hatten, ahnten
>>wir nicht, welche Ausmaße das Projekt annehmen würde.
>>Sonst hätten wir gleich mit C++ losgelegt. Jetzt will
>>es wohl überlegt sein. Wohler überlegt, als ein OS-Wechsel :-)
>>Denn Kunden wollen ggf.: Apache, Zeus, IIS, MySQL, PostgreSQL,
>> Oracle, DB2, Sybase SQL, MS SQl Server, ausführbare Skripte,
>> ... - das programmiere mal in C++ mit einem einheitlichen
>>Interface, wie es bei einem Applikationsserver nötig ist.
>
> Hätte man sich nicht Jahre mit PHP rumgeschlagen, sondern mit C++,
> dann wäre das damit letzlich genauso einfach...

Leider nein. Wir haben uns die Zeit über mit dem Objektdesign
unseres Frameworks vertrieben, das nach C++ umzustellen wäre
eine Sache von wenigen Wochen. Kritischer wird's mit dem
Anbinden der Backends.

> Aber ich habe auch meine Altlasten - teilweise, weil ich fertiges
> übernehmen musste.

Oh, wir haben uns damals freiwillig dafür entschieden, weils
schneller Ergebnisse lieferte. War uns wichtiger. Wie gesagt,
knapp 80% der Laufzeit geht für externe Aufrufe drauf.

Aber der Tag der Umstellung wird kommen :-)
Wenn's nach mir geht, eher früher als später. Aber dafür
ist noch einiges an Recherchearbeit nötig. Immerhin
möchte ich den Kommunikationsaufwand mit dem Webserver
möglichst gering halten, ohne einen eigenen entwickeln
zu müssen.

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 - 23:07:29 CET