Wie sieht der ideale Webserver aus?

[Speedy.]

Hallo zusammen,

ich stelle mir in letzter Zeit vermehrt die Frage, wie der ideale Webserver bzw. dessen Software in Bezug auf Performance, Sicherheit und Stabilität aussehen mag. Aus diesem Grund wollte ich eure Meinungen dazu hören.

Ausgehen tuhe ich von Ubuntu 14.04. Darauf laufen soll ein relationales DBMS und PHP, ausgeliefert werden dann dynamische Webseiten. Nach meinem jetzigen Wissensstand wäre dies meine bevorzugte Konstellation:

- Ubuntu 14.04 (Server)
- MariaDB
- PHP 5.6 als FastCGI-Modul
- nginx

Gibt es da mehr rauszuholen? Es gibt ja auch alternative PHP-Varianten, die deutlich mehr Leistung haben, aber teilweise Kompatibilitätsprobleme machen. Was haltet ihr davon?

Grüße
Speedy

 

[metalpinguin]

Also


php-fpm statt fcgi

und ggf. Litespeed als webserver was für Anwendungen sollen drauf laufen? Jenach dem gibt es noch weitere Sub dienste wie memcache,redis,varnish usw.

 

[Speedy.]

Ok, von PHP-FPM habe ich auch schon gutes gehört.
Meine Frage ist eher grundsätzlicher Natur. Aber unter Umständen wird das Team, in dem ich arbeite, bald unser Intranet für 2000 Mitarbeiter programmieren, und da wollte ich mich ein bisschen schlau machen. Ich würde dieses dann gerne mit PHP und einem Framework wie Laravel oder Symfony2 umsetzen. Noch steht es aber kontra einem Baukasten auf Java-Basis

Edit: ich glaube auch nicht, dass wir diese Performance benötigen (wahrscheinlich würde es da ein Apache2 mit mod_php tun), aber ich bin immer gerne informiert über bessere Möglichkeiten.

 

[metalpinguin]

PHP-FPM steht ja für PHP-FCGI Process Manager. Ist somit eigntlich ein fcgi übergelagerter Dienst der das Starten und das Handling der fcgi also PHP Processe übernimmt. Mit mehr Konfigoptionen und Stabilitätsverbesserungen gegen über einfachem fcgi. Dies gilt für Apache, Nginx und Litespeed.

Bezüglich den ganzen Benchmarks Apache vs Nginx, viele implementieren mit nginx direkt php-fpm anstatt mod_php oder ähnlichem bei Apache und vergleichen dann diese Unterschiedlichen PHP Implementationen.
Aber wenn du Apache und Nginx mit PHP-FPM einrichtest ist die reine PHP Performance identisch nur kann nginx die Statischen Files etwas effizienter ausliefern.


Ich würde mir aber angucken die Sessions bzw Caches des jeweiligen Frameworks in Redis z.B. abzulegen dies ist schneller als File oder MySQL.

Zu allen Serverseitigen Optimierungen ist jedoch zusagen:

Wenn du das meist ausgeführte SQL Query optimierst holst du oft mehr raus als mit dem wechsel auf MariaDB oder PerconaSQL zu MySQL oder Parameteroptimierungen für MySQL.

Es steckt dort SEHR SEHR VIEL VOODOO in Blogposts

 

[asdfman]

Der beste Webserver ist in C gehackt, mit dietlibc, libowfat, unter gatling laufend und mit einem tinyldap-Backend.

 

[Daaron]

Edit: ich glaube auch nicht, dass wir diese Performance benötigen (wahrscheinlich würde es da ein Apache2 mit mod_php tun), aber ich bin immer gerne informiert über bessere Möglichkeiten.

Läuft nur eine einzige Seite, ein einziger User? Dann kannst du tatsächlich einfaches Apache2-MPM-Prefork mit Mod_PHP verwenden.
Wenn du mehrere Seiten hast, die auf separaten Usern laufen, dann kann ich dir nur zu Apache2-MPM-ITK raten. Zwar sind einige andere MPM-Implementierungen einen Hauch schneller, aber die nerven hinsichtlich Stabilität oder dem Zwang, FCGI zu verwenden. Außerdem muss man sich da teilweise noch SUEXEC antun...

Insgesamt würde ich immer wieder auf Apache2-MPM-ITK mit PHP-FPM setzen. Das ganze Konstrukt ist extrem flexibel, schnell und unschlagbar übersichtlich zu konfigurieren.
nginx ist etwas schneller, dafür ist die Konfiguration deutlich unübersichtlicher/komplexer.

Was, nach allem was ich darüber gelesen habe, wirklich einen Blick wert ist, ist der Cherokee Server. Das Teil ist irgendwo zwischen dem puristischen Ansatz von nginx und der Flexibilität und Konfigurierbarkeit von Apache angesiedelt, und soll verdammt schnell sein.

Was du auf keinen Fall vergessen darfst, ist ein PHP OpCode-Cache.

Aber wenn du Apache und Nginx mit PHP-FPM einrichtest ist die reine PHP Performance identisch nur kann nginx die Statischen Files etwas effizienter ausliefern.

Apache hat noch einen kleinen Nachteil in der Performance: .htaccess. Diese Files sind zwar grandios, um sehr flexibel ordnerbasiert Rechte zu vergeben, Rewrites zu konfigurieren,..., aber blöderweise muss bei jedem Aufruf der gesamte Baum rekursiv durchlaufen werden.
Man kann im Zweifel, wenn die statischen Ressourcen wirklich so lahm sind, ja auch einen nginx als Cache einrichten.

Ich würde mir aber angucken die Sessions bzw Caches des jeweiligen Frameworks in Redis z.B. abzulegen dies ist schneller als File oder MySQL.

Redis ist eine Option, aber es gibt noch ein paar andere schöne Lösungen dafür, z.B.:
- RAM-Disk... Spart viel Konfiguration/Entwicklung. Man tauscht nur den normalen PHP Session Ordner gegen einen RAM-Ordner. Dafür braucht es nur ein kleines Script, so dass der Server beim Reboot den Ordner erstellt. Ein komplexeres Script kann vor (geplantem) Herunterfahren den Inhalt der RAM-Disk auf die Festplatte schreiben und nach dem Reboot wiederherstellen.
Bei nem Crash ist natürlich alles flöten, aber das trifft auf jede nicht 100% ACID-konforme Lösung zu.
- Memcached... Sehr feines Ding. Ist natürlcih 100% flüchtig, sogar ein "service memcache restart" killt die Daten, aber dafür ist Memcache sehr flexibel und leicht zu bedienen. Ein paar Zeilen PHP-Code sorgen schon dafür, dass man Werte in den Cache ballert oder herausholt.

Wenn du das meist ausgeführte SQL Query optimierst holst du oft mehr raus als mit dem wechsel auf MariaDB oder PerconaSQL zu MySQL oder Parameteroptimierungen für MySQL.

Das mag stimmen, aber es schadet nicht, von Anfang an auf MariaDB zu setzen. Im schlimmsten Fall ist man nur genauso schnell wie mit MySQL. Im besten Fall hingegen rockt es einfach nur. Außerdem kann MariaDB ein paar Zaubertricks, die MySQL eben nciht drauf hat, z.B. einen eigenen (noch etwas rudimentären) NoSQL-Ansatz.

Der beste Webserver ist in C gehackt, mit dietlibc, libowfat, unter gatling laufend und mit einem tinyldap-Backend.

Das mag sein, aber wer tut sich so ein Machwerk freiwillig an? Jedes Mal, wenn du etwas Programmlogik umschreiben willst, musst du allen Scheiß neu kompilieren.

 

[Speedy.]

Insgesamt würde ich immer wieder auf Apache2-MPM-ITK mit PHP-FPM setzen. Das ganze Konstrukt ist extrem flexibel, schnell und unschlagbar übersichtlich zu konfigurieren.

Ok, dass schaue ich mir genauer an. Die Seite wird wenn nur auf einem User laufen, von daher dürfte es der Apache2-MPM tun.

Was, nach allem was ich darüber gelesen habe, wirklich einen Blick wert ist, ist der Cherokee Server. Das Teil ist irgendwo zwischen dem puristischen Ansatz von nginx und der Flexibilität und Konfigurierbarkeit von Apache angesiedelt, und soll verdammt schnell sein.

Den habe ich bereits mal vor einiger Zeit getestet, leider ohne große Benchmarks. Aber das Teil ist wirklich einen Blick wert, in meinen wenigen Tests unglaublich schnell und leicht zu bedienen, da er eine recht überschaubare GUI auf Python-Basis hat. Da frage ich mich aktuell noch, ob man auf Altbewährtes oder etwas Neues setzen soll. Persönlich fühle ich mich zu dem Cherokee mehr hingezogen.

Was du auf keinen Fall vergessen darfst, ist ein PHP OpCode-Cache.

Da diese Funktion seit PHP 5.5 eingebaut ist und ich sowieso auf die neueste Version setzte, sollte das ja kein Problem sein.

Der beste Webserver ist in C gehackt, mit dietlibc, libowfat, unter gatling laufend und mit einem tinyldap-Backend.

Ich glaube, dass übersteigt meine Fähigkeiten

Auf jeden Fall vielen Dank für die interessanten Antworten, dass hat mir ein gutes Stück weitergeholfen!

 

[Daaron]

Ok, dass schaue ich mir genauer an. Die Seite wird wenn nur auf einem User laufen, von daher dürfte es der Apache2-MPM tun.

Ja, wenn du nicht mehrere unabhängige VHosts betreiben willst, dann ist ITK nicht sinnig. Da solltest du evtl. einen Blick auf MPM-Worker werfen. Worker ist richtig brutal schnell, schließt aber z.B. mod_php grundsätzlich aus, FCGI (z.B. PHP-FPM) ist Pflicht. Für Rechtemanagement müsste man halt Suexec dazwischen schalten.

Da diese Funktion seit PHP 5.5 eingebaut ist und ich sowieso auf die neueste Version setzte, sollte das ja kein Problem sein.

Stimmt, da Trusty Thar auf PHP 5.5 und Apache 2.4 setzt, hast du hier kein Problem.

Ich glaube, dass übersteigt meine Fähigkeiten

Da gehts nicht nur dir so. Wie gesagt, solche Lösungen sind unendlich schnell (wenn mans richtig macht), aber dafür eben auch unendlich kompliziert hinsichtlich Wartung und Erweiterung.
Wenn man auf eine der üblichen Sprachen, also PHP, ASP.NET, Ruby,... setzt und mal was ändern will, dann findet man schnell jemandem, der neue Features implementieren kann. Ich für meinen Teil möchte mich nicht in einen wildfremden C-Server einarbeiten müssen. Bei den Interpreter-Sprachen kann man wenigstens bei Problemen direkt auf Echo-Debugging setzen....

Meine Wahl wäre immer PHP. Mit OpCode-Cache ist es schnell genug für die meisten Probleme und wenn alle Stricke reißen gibts ja noch HipHop.

 

[Speedy.]

Ja, wenn du nicht mehrere unabhängige VHosts betreiben willst, dann ist ITK nicht sinnig. Da solltest du evtl. einen Blick auf MPM-Worker werfen. Worker ist richtig brutal schnell, schließt aber z.B. mod_php grundsätzlich aus, FCGI (z.B. PHP-FPM) ist Pflicht. Für Rechtemanagement müsste man halt Suexec dazwischen schalten.

Mehrere vHosts machen aus meiner Sicht bei dem Projekt keinen Sinn. Von daher plane ich erst einmal ohne. Wenn ich die Sache mit MPM richtig verstehe behebt es den Nachteil von Apache, alles in einem Single Thread abzuarbeiten. So werden die Aufgaben auf verschiedene Multithreads und Prozesse ausgelagert, was die Performance erhöht und den Verbrauch der Systemreccourcen reduziert, oder?

Stimmt, da Trusty Thar auf PHP 5.5 und Apache 2.4 setzt, hast du hier kein Problem.

Und selbst wenn es bei 14.04 nicht dabei wäre: PPA oder selbst kompilieren. So hat man unter Umständen mit einem späteren Update Probleme, aber das weiß man ja vorher. Da der Server wenn komplett durch uns verwaltet wird, mache ich mir keine Sorgen. Bleibt nur zu hoffen, dass der Chef nicht beschließt, dass Ding auf Windows Server zu drehen...

Meine Wahl wäre immer PHP. Mit OpCode-Cache ist es schnell genug für die meisten Probleme und wenn alle Stricke reißen gibts ja noch HipHop.

Meine auch. PHP ist mir sympatischer als Java oder eine C-basierte Sprache und erfüllt im Grunde alle Anforderungen. Es kann sogar mit ABAP-Funktionsbausteinen kommunizieren und gegen das Active Directory authentifizieren. Und für solche Sachen wie HipHop ist die Anwendung einfach nicht komplex genug, da haben es Facebook und co. nötiger.

 

[Daaron]

Mehrere vHosts machen aus meiner Sicht bei dem Projekt keinen Sinn. Von daher plane ich erst einmal ohne. Wenn ich die Sache mit MPM richtig verstehe behebt es den Nachteil von Apache, alles in einem Single Thread abzuarbeiten. So werden die Aufgaben auf verschiedene Multithreads und Prozesse ausgelagert, was die Performance erhöht und den Verbrauch der Systemreccourcen reduziert, oder?

Na ja, nicht ganz. MPM heißt ja nur "Multi Process Manager". Normalerweise arbeitet MPM-Prefork, also der Basis-MPM, von dem alle anderen Entwicklungen Forks sind. Sowohl MPM-Prefork als auch MPM-ITK sind nicht threaded, da PHP nicht Thread-sicher ist. Du hast statt dessen mehrere unabhänge Prozesse für die verschiedenen Requests. Da KANN es eben sein, dass für jeden Request ein fork() durchgeführt wird, um einen neuen Prozess zu starten, das sorgt für Overhead. Da die Lösungen aber thread-safe sind, kannst du hier auf mod_php setzen.

Es gibt ein paar neuere, Thread-basierte MPMs, eben z.B. Worker. Hier kannste viele Threads in einem Prozess abwickeln, hast dadurch keinen Overhead durch fork(). Das ist natürlich viel viel schneller. Dafür bist du bei PHP zwingend darauf angewiesen, dass sich jemand anderes um die Thread-Sicherheit kümmert... eben ein CGI-Ansatz.
Die Nachteile von Worker-Threads sind halt, dass du einerseits kein mod_php (oder *grusel* suPHP) verwenden kannst, andererseits bist du für saubere Trennung der verschiedenen vHosts (phpMyAdmin ist im Endeffekt auch einer) auf Suexec angewiesen.

Für PHP-Inhalte ist MPM-Prefork nicht langsamer als MPM-Worker (und auch nicht als nginx), vorausgesetzt man verwendet PHP-FPM. Nur bei den statischen Ressourcen macht es einen echten Unterschied.
Da man, wenn man clever ist, statische Ressourcen aber eh soweit es geht in CDNs auslagert, ist das vollkommen Banane.

Statt also am Webserver herumzufummeln, denk lieber über CloudFlare nach. Gratis (ohne SSL) oder 20$/Monat (mit SSL), dafür ist die Bandbreite unschlagbar und du bist sogar fast immun gegen DDoS.
Oder setz dich mal mit den CB-Admins in Verbindung. Wenn ich mich recht erinner läuft CB auf 2 Apachen mit Loadbalancer hinter nem nginx als Proxy.

 

[mambokurt]

- MariaDB

MySQL/MariaDB sind performancemäßig ziemliche Stolperstricke wenn man sie nicht richtig einstellt. Wenn du über Tabellen mit mehr als 10.000 Einträgen nachdenkst oder einfach nur ein Statement falsch struturierst kann dir das ganz schnell das Genick brechen. Ich würde dann eher auf PostgreSql gehen oder sogar auf SQLite, je nach Anwendung.

Ansonsten kommt es stark auf die Anwendung an. Für ein bisschen Webseitenausgeliefer brauchst du keine Supersoftware, und 0,2 Sekunden Rechenzeit schei**en sich eigentlich weg bei den Ladezeiten einer normalen Internetverbindung. Da ist die Seite schon 20x fertig ausgeliefert und der Browser lädt trotzdem noch an irgendwelchen 20kb Grafiken rum. In meinen Szenarien waren die Zeitfresser eigentlich immer a) Datenbank b) Datenbank c) Datenbank d) nicht optimierter Code in PHP und e) Netzwerk, da war es nie so dass der Webserver oder die Sprache viel hätten reissen können.

 

[Kanibal]

Moment - Du bist aber nicht der fette fefe?

 

[Daaron]

MySQL/MariaDB sind performancemäßig ziemliche Stolperstricke wenn man sie nicht richtig einstellt.

So schwer sind diese Einstellungen aber auch wieder nicht...

Für ein bisschen Webseitenausgeliefer brauchst du keine Supersoftware, und 0,2 Sekunden Rechenzeit schei**en sich eigentlich weg

Falsch. 200ms Time To First Byte mehr machen einen gewaltigen Unterschied... spätestens im Google Ranking schlägt sich so etwas negativ nieder.

Da ist die Seite schon 20x fertig ausgeliefert und der Browser lädt trotzdem noch an irgendwelchen 20kb Grafiken rum.

Wieder falsch, und zwar gleich mehrfach
- Es gibt keine Seite, die ausgeliefert werden könnte, wenn der Server noch blöd rumrechnet. Die 200ms machen hier sehr viel aus.
- Hieraus ergibt sich, dass all die zusätzlichen Inhalte auch erst 200ms später anfangen zu laden.
- Diese zusätzlichen Inhalte werden beim User gecached. Er lädt sie weitestgehend nur 1x. Die 200ms hast du immer wieder an der Backe. Blöde Sache
- Zusätzliche Inhalte kann man auf CDNs auslagern. Außerdem verwendet man keine 20kB-Grafiken, man verwendet CSS Sprites.
- Spätestens wenn du stark auf AJAX setzt, machen sich die 200ms sehr deutlich bemerkbar

In meinen Szenarien waren die Zeitfresser ... da war es nie so dass der Webserver oder die Sprache viel hätten reissen können.

Deine Szenarien umfassen scheinbar auch nur Seiten mit wenigen 100 Hits am Tag...
Wenn du erst einmal zu jedem Zeitpunkt dreistellige Requests hast, wirst du dir schon über deine Server-Einstellung Gedanken machen.

 

[mambokurt]

So schwer sind diese Einstellungen aber auch wieder nicht...

Stellt sich die Frage, warum man ein System einsetzen soll bei dem die Standardeinstellungen Optimierungsbedarf haben wenn man auch relativ stressfrei ein anderes DBMS haben kann. Alle DBMS haben ihre Stolperstricke, aber MySQL hat gerade performanceseitig ziemliche Stolperstricke. Da würd ich schon überlegen einfach ein anderes DBMS zu nehmen wo es einfach so läuft.

Falsch. 200ms Time To First Byte mehr machen einen gewaltigen Unterschied... spätestens im Google Ranking schlägt sich so etwas negativ nieder.

Und du weisst dass er auf Google gefunden werden will weil... Du und ich gehen beide von unseren jeweiligen Anwendungen aus, wer von uns beiden näher dran ist kann nur der TE beurteilen.

Wieder falsch, und zwar gleich mehrfach
- Es gibt keine Seite, die ausgeliefert werden könnte, wenn der Server noch blöd rumrechnet. Die 200ms machen hier sehr viel aus.
- Hieraus ergibt sich, dass all die zusätzlichen Inhalte auch erst 200ms später anfangen zu laden.
- Diese zusätzlichen Inhalte werden beim User gecached. Er lädt sie weitestgehend nur 1x. Die 200ms hast du immer wieder an der Backe. Blöde Sache
- Zusätzliche Inhalte kann man auf CDNs auslagern. Außerdem verwendet man keine 20kB-Grafiken, man verwendet CSS Sprites.
- Spätestens wenn du stark auf AJAX setzt, machen sich die 200ms sehr deutlich bemerkbar

Mit schei**en sich weg meinte ich: wenn du die Seite anforderst, der rödelt 0,5 Sekunden auf dem Server, beginnt mit der Auslieferung und braucht dafür dann 5 Sekunden um das ganze Zeug übers Netzwerk zu pumpen, dann relativieren sich die 0,5 Sekunden Gerödel auf dem Server so ziemlich. Klar schleppst du die immer mit, klar ist weniger besser. Aber ob es sich lohnt da rumzuoptimieren weiss auch wieder nur der TE.

Deine Szenarien umfassen scheinbar auch nur Seiten mit wenigen 100 Hits am Tag...
Wenn du erst einmal zu jedem Zeitpunkt dreistellige Requests hast, wirst du dir schon über deine Server-Einstellung Gedanken machen.

Wir haben einfach unterschiedliche Anwendungen: bei mir laufen eher wenige Hits auf die aber massiv Datenbanknutzung und Rechenzeit brauchen, bei dir eher viele kleine Anfragen (wenn ich das richtig verstehe). Was jetzt eher auf den TE zutrifft muss er entscheiden. Ich wollte eigentlich nur sagen, dass er sich nicht im Vorfeld kapputtoptimieren soll wenn er die Arbeitszeit auch produktiver nutzen könnte.

 

[Daaron]

Stellt sich die Frage, warum man ein System einsetzen soll bei dem die Standardeinstellungen Optimierungsbedarf haben...

Weil sie der Markt-Standard sind, weil sie überall verfügbar sind. LAMP ist deutlich weiter verbreitet und besser dokumentiert als LAPP.

Und du weisst dass er auf Google gefunden werden will weil...

...weil die meisten Webserver dazu da sind, ÖFFENTLICHE Inhalte auszuliefern und mit diesen Inhalten auf die eine oder andere Weise Geld zu verdienen. Das heißt: SEO SEO SEO

Mit schei**en sich weg meinte ich: wenn du die Seite anforderst, der rödelt 0,5 Sekunden auf dem Server, beginnt mit der Auslieferung und braucht dafür dann 5 Sekunden um das ganze Zeug übers Netzwerk zu pumpen...

...beim ersten Request. Bei folgenden Requests springt der Cache in die Bresche und es wird nur der (gezippte) HTML-Code übertragen, keine Stylesheets, keine JS-Files, keine Icon-Sets, keine Fonts,...
Wenn man also schon darüber nachdenkt, wie wohl der ideale (Mehrzweck-?) Webserver aussieht, dann sollte man GERADE die Frage nach Time to First Byte unter Hochlast-Situationen stellen. Eine Bananen-Seite mit 100 Hits am Tag liefert auch ne Raspberry PI in Standard-Einstellung zügig genug aus.

Wir haben einfach unterschiedliche Anwendungen: bei mir laufen eher wenige Hits auf die aber massiv Datenbanknutzung und Rechenzeit brauchen, bei dir eher viele kleine Anfragen (wenn ich das richtig verstehe).

Der ideale Webserver kann beides, und die ideale Webanwendung beherrscht Caching, um genau diese Rechenzeit selten anfallen zu lassen.

Ich wollte eigentlich nur sagen, dass er sich nicht im Vorfeld kapputtoptimieren soll wenn er die Arbeitszeit auch produktiver nutzen könnte.

Es ist kein "kaputtoptimieren" und erst reicht keine Verschwendung von Arbeitszeit, wenn man im Vorfeld einfach mal in die Runde fragt, welches Setup wohl global betrachtet die meiste Leistung bringen wird.
Was bringt es mir, wenn ich (mangels Vorkenntnisse) mit Apache2-MPM-Prefork UND Mod_PHP anfange, nur um dann nach einigen Wochen endloser Ladezeit und Fehlersuche festzustellen, dass z.B. MPM-Worker + PHP-FPM von Anfang an das Problem verhindert hätten?

Wenn man einen Webserver neu aufsetzt, dann sollte man es direkt richtig machen. DAS ist effizientes Arbeiten. Wenn das heißt, dass man sich noch ein paar zusätzliche Informationen einholt anstatt einfach das "LAMP"-Paket bei Tasksel zu wählen, dann ist das gut investierte Zeit.
Ich investieren regelmäßig Arbeitszeit in Weiterbildung und neue Grundlagen. Nicht alle Informationen kann ich profitabel zur Anwendung bringen, aber die, die ich dann anwenden kann, relativieren den vorherigen Aufwand doppelt und dreifach.

 

[mambokurt]

Weil sie der Markt-Standard sind, weil sie überall verfügbar sind. LAMP ist deutlich weiter verbreitet und besser dokumentiert als LAPP.

.... was nichts daran ändert das MySQL bzw MariaDB (so sehr unterscheidet sich das momentan nicht) bei manchen Querietypen absoluter Schmutz sind. Dokumentiert hin oder her: ich habe ihn gewarnt dass er vielleicht Probleme mit der Performance bekommen könnte, das empfinde ich als produktiven Beitrag.

...weil die meisten Webserver dazu da sind, ÖFFENTLICHE Inhalte auszuliefern und mit diesen Inhalten auf die eine oder andere Weise Geld zu verdienen. Das heißt: SEO SEO SEO

Kannst du das mit Quellen belegen? Ich denke das durchaus auch, aber gerade in Zeiten wo private Server erschwinglich sind baut man eben auch mal fix einen Stillkalender für die Freundin oder einen Terminkalender für die Verwandschaft -.- Da ist SEO natürlich immens wichtig. Der TE hat zu dem Punkt 0 Infos bereitgestellt, du rätst hier ins blaue und nillst mich deshalb voll - begreifst du die Problematik

...beim ersten Request. Bei folgenden Requests springt der Cache in die Bresche und es wird nur der (gezippte) HTML-Code übertragen, keine Stylesheets, keine JS-Files, keine Icon-Sets, keine Fonts,...
Wenn man also schon darüber nachdenkt, wie wohl der ideale (Mehrzweck-?) Webserver aussieht, dann sollte man GERADE die Frage nach Time to First Byte unter Hochlast-Situationen stellen. Eine Bananen-Seite mit 100 Hits am Tag liefert auch ne Raspberry PI in Standard-Einstellung zügig genug aus.

EBEN. Die Frage nach Hits hast du aber nie gestellt, oder?

Der ideale Webserver kann beides, und die ideale Webanwendung beherrscht Caching, um genau diese Rechenzeit selten anfallen zu lassen.

Der ideale Webserver ist ein Quantencomputer der über PCIE direkt mit dem Client verbunden ist und Blitze aus seinem Ars** schießen kann, um Braveheart zu zitieren. Die Frage ist was man bereit ist in die Konfiguration zu stecken und was man zurück bekommt. Mit einem stinknormalen Lamp System wirst du 95% der Anwendungsszenarien für normale Websites locker wegklatschen. Dann erst kommst du in Regionen mit LightHttpd und Nginx und wasimmer. Da wär ich dann aber eher am Überlegen ob sich nicht ne SSD im Server 5x mehr rentiert als das rumkonfigurieren am Webserver.

Es ist kein "kaputtoptimieren" und erst reicht keine Verschwendung von Arbeitszeit, wenn man im Vorfeld einfach mal in die Runde fragt, welches Setup wohl global betrachtet die meiste Leistung bringen wird.
Was bringt es mir, wenn ich (mangels Vorkenntnisse) mit Apache2-MPM-Prefork UND Mod_PHP anfange, nur um dann nach einigen Wochen endloser Ladezeit und Fehlersuche festzustellen, dass z.B. MPM-Worker + PHP-FPM von Anfang an das Problem verhindert hätten?

Es ist aber kapputtoptimieren wenn ich blind Tipps folge und mir Arbeit mache und einen Webserver aufsetze, der im Endeffekt 20h Installation erfordert, aber nur 100ms beim ausliefern einspart bei 5 Hits am Tag. Man arbeitet nach bestem Wissen und nach Möglichkeit effizient, optimiert wird erst wenn es zu langsam wird. PUNKT.

Wenn man einen Webserver neu aufsetzt, dann sollte man es direkt richtig machen.

Nö, wenn ich weiss da läuft irgendeine Gurkenseite drüber die der Apache mit links und 40 Fieber handelt schert mich das genau gar nichts. Die Zeit das einzurichten bezahlt mir nicht nur keiner, die ist im Zweifelsfall auch noch total sinnfrei rausgeblasen.

Ich investieren regelmäßig Arbeitszeit in Weiterbildung und neue Grundlagen. Nicht alle Informationen kann ich profitabel zur Anwendung bringen, aber die, die ich dann anwenden kann, relativieren den vorherigen Aufwand doppelt und dreifach.

Ist für das Thema so relevant wie der sprichwörtliche Sack Reis. Bevor der TE nicht seine Anforderungen spezifiziert würde ich aber sagen wir lassen es an der Stelle gut sein, es bringt gar nichts sich hier zu fetzen solange wir nicht wissen was das Anwendungsszenario ist....