Re: OpenBSD

On Sun, Oct 26, 2003 at 06:42:37PM +0000, Jens Rehsack wrote:
> Bernd Walter wrote:
> >On Sun, Oct 26, 2003 at 05:20:45PM +0000, Jens Rehsack wrote:
> >>Web-Seite, sondern man wahr stolz auf die poll()-Abfrage)
> >
> >Poll mag schneller sein, als eine Threaded Umgebung.
>
> Sicher, sicher. Mag, oder mag nicht. Ich habe für sowas
> in früheren Projekten gern select() genommen und hatte
> Threads, die auf eine Mutex gewartet haben. Das ging
> sehr schön und hatte den netten Vorteil, das es gut
> skalierte. Ich persönlich sehe auf der Manpage den Vorteil
> von poll() gegenüber select() nicht. Im Linux hatte
> ich früher mal geschaut, was so ein select() macht:
> if( !_poll() ) { usleep(); } (so im Groben und Ganzen).
> Ohne jetzt im BSD suchen zu wollen vermute ich
> da ähnliches.

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.

> >>noch mit PHP vernünftig klar kommt. Jedesmal einen
> >>PHP-Interpreter laden, das würde vermutlich alles zunichte
> >>machen, was er an Leistungsvorteilen mitbringt.
> >
> >Die Verwendung von PHP macht das streben nach Performance bereits
> >Absurd.
>
> Nicht wirklich. Ab einer bestimmten Konstante der
> Probleme (z.B. mit XSLT gerenderte XML Dokumente)
> ist der Zusatzaufwand vom PHP recht klein. Außerdem
> hat der PHP-Interprete z.B. eine stat()-Cache,
> eine recht gute File-I/O, ... - alles Sachen, die
> ich in C/C++ teuer nachbauen müsste. Für den
> Preisvorteil bekomme ich einige zusätzliche
> Web-Server. Und unser z.Zt. größter Brocken in
> der Bearbeitung liegt im XSLT-Rendern mit knapp
> 80% Zeitanteil an der Berechnung. Und Sablot ist
> in C++ geschrieben, und der Code sieht auch sehr
> gut designt aus.

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

> 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.

> Aber auch da ist PHP selbst nicht die Bremse.

Eben doch.

> 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.

> 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.
Du kannst eher anfangen Teilsysteme zu portieren - wenn das Kind schon
im Brunnen gefallen ist.

> >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.

> >thttpd hat ebenfalls nichts von SMP, kann aber richtig eingesetzt
>
> Schade, eigendlich.

Warum?
SMP ist erst mal eine Bremse, genauso Threads.
Der Verlust muss erst mal wieder kompensiert werden.
Und ein Webserver soll erst mal TCP Requests abhandeln - problemlos
auf mehrere Maschinen/Prozesse verteilbar.
Die dahinterliegende Datenbank ist das, was man nicht mehr so einfach
verteilen kann.
Wenn du tatsächlich eine 2 CPU Maschine im Frontend hast, dann startest
du halt zwei Instanzen und das wars - ohne Thread Overhead.

> >allemal mehr Leistung bringen, als irgendein SMP gestütztes PHP Zeugs.
>
> :-)
> Da sind wir uns wohl alle einig. Aber leider habe ich
> keine Gelddruckmaschine im Keller um die Entwicklung
> der Umstellung auf C++ zu bezahlen. Also muss es die
> PHP-Variante noch 'ne Weile tun.

Jaja - die berühmten Altlasten.

> 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...
Aber ich habe auch meine Altlasten - teilweise, weil ich fertiges
übernehmen musste.

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