Re: OpenBSD

Bernd Walter wrote:
> On Sun, Oct 26, 2003 at 05:20:45PM +0000, Jens Rehsack wrote:

> Wenn es um Performance und Features geht, dann ist PostgreSQL durchaus
> brauchbar - und für den Preis eines Kommerziellen SQL kann man meist
> auch die Hardware für einen getrennten Datenbank Server bekommen.

Oh ja, und zwar ordentliche.

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

>>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.
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.
Aber auch da ist PHP selbst nicht die Bremse.
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.

Da macht es doch eher Sinn, erstmal zu tunen,
was man hat, und parallel dazu auf C++ umzustellen.

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

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

Schade, eigendlich.

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

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.

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 - 19:43:16 CET