Von wegen tot: So wurde PHP ultra schnell!

[DMW007]

Das Web (für viele synonym mit dem "Internet") baut auf PHP. Doch PHP hat einen schlechten Ruf als langsam & ineffizient. Das war es tatsächlich mal, doch in den letzten ~13 Jahren gab es massive Verbesserungen! OPcache wurde in PHP integriert und löst das leidige Problem von Skriptsprachen: Der Interpreter muss ständig das gesamte Skript ausführen. Dank Bytecode gehört das bereits seit Jahren der Vergangenheit an. JIT hebt dies in PHP 8 auf ein neues Level, in dem sogar Maschinencode erzeugt & zwischengespeichert wird. Noch mehr Leistung lässt sich durch das Zwischenspeichern von Variablen heraus holen. Früher war Xcache verbreitet, seit PHP 5.5 ist APCu der Standard. Im Video beschreibe ich diese Technologie mit ihren Entwicklungen. Außerdem ein Performance-Killer, den viele Entwickler gar nicht auf dem Schirm haben. Alle Infos mit Quellen hier: Zum kompletten Beitrag im U-Labs Portal

[U-Labs YouTube]

Antwort von @deadeye1982a:
[9:20] Ja, diese Erfahrung habe ich mit SQLAlchemy (Python) auf einem RPi gehabt. Aufgrund der SD-Karte, hat man recht geringe IOPS, was das Laden von vielen kleinen Dateien unheimlich verlangsamt. Die gleiche Funktionalität hätte ich ohne das Framework mit weniger Code erzielen können. Es ist nicht immer gut, mit Kanonen auf Spatzen zu schießen.

[U-Labs YouTube]

Antwort von @Kmonki:
Dient doch nur den Framework-Junkies...

Schon mal eine richtig fette Webanwendung ohne Frameworks geschrieben?
Ich hab selbst auf dem schlechtesten PC (als Server) unbegrenzt Leistung. Für richtig dicke Software mit 50000 verschiedenen Live Daten macht es Sinn eine DB Tabelle in den RAM auszulagern und immer nur einen Stand von wenigen Sekunden zu halten der dann berechnet in die dauerhafte DB-Tabelle schreibt. Ansonsten läuft das alles so extrem schnell (wenn man richtig coden kann) das man sowas nicht braucht... Außer man hat Frameworks die +500MB groß sind weil man die Schrift auf der Seite in einer bestimmten Farbe haben will

[U-Labs YouTube]

Antwort von @n4botz:
Das ist falsch und dein Ansatz völlig altbacken, weil PHP-Anwendungen keinen persistenten RAM über Requests hinweg haben - ein RAM-Stand pro Tabelle existiert also gar nicht zuverlässig. Bei vielen Nutzern verursacht nicht der PHP-Code, sondern die Datenbankabfragen die meiste Last, und genau dafür sind DB-Engines mit Indizes, Joins, Transaktionen und Caching optimiert. Alles selbst im RAM zu halten (egal wie lange) würde Konsistenz und Skalierbarkeit zerstören und eigene Server teils deutlich mehr belastet, statt die Performance gescheit zu verbessern. Frameworks wie z.B. Laravel sind auch kein unnötiger Ballast, sondern liefern bewährte Strukturen, Sicherheit, DB-Abstraktion (ORM, Query Builder) und Caching, die man sonst selbst (und nicht unbedingt besser) implementieren müsste.

Um beim genannten Beispiel zu bleiben: Laravel handhabt große Datenmengen effizient, indem nur benötigte Datensätze geladen, Queries über Indizes optimiert und optional In-Memory-Caches wie Redis genutzt werden, sodass viele Nutzer gleichzeitig arbeiten können. Berechnungen laufen hingegen über Queues und Hintergrundjobs, während Transaktionen die Konsistenz garantieren. Ein selbstentwickelter RAM-Stand ist völlig unnötig und zu riskant, weil er weder Skalierbarkeit noch Datenintegrität sicherstellt. Probleme wie Race Conditions, Multi-User-Zugriff und fehlendes zentrales Caching machen deinen Ansatz extrem fehleranfällig. Wer so argumentiert und mit einem Ansatz von Anno Zwieback ankommt, eigentlich weder moderne Serverarchitektur noch skalierbare Webentwicklung versteht.

Kurz und knapp: Nein, es macht keinen Sinn derlei Daten im RAM zu parken/auszulagern.

[U-Labs YouTube]

Antwort von @Kmonki:
@n4botz offensichtlich bist du noch nicht lange dabei und hast nur gelernt KIs zu bedienen (nicht böse gemeint)

Ich bin seit 30 Jahren Entwickler, ich schreibe Code fließend von Hand und ohne externe Abhängigkeiten die zu schwerwiegenden Sicherheitsfehlern und/oder Totalausfällen führen. Daher finde ich dein "Falsch" sehr sehr lustig.... So nach dem Motto "wenn ich nicht in der Lage bin, ist es niemand"

Aber fairerweise muss ich sagen das deine Ansicht auf die meisten 08/15 "Entwickler" zutrifft. Leute wie ich, also die extreme Expertise vorweisen können, fahren mit eigenem Code viel viel besser. Gerade wenn du Aufträge von Banken, Militär oä. bekommst, da gelten höhere Standards als auf ner privaten Portfolioseite. Vor allem auch der Umgang mit echtem Big-Data ist mit Framework-Müll nichts anzufangen

[U-Labs YouTube]

Antwort von @Kmonki:
Wenn du irgendwann mal ein Paar verschiedene Projekte selbst geschriebn haben solltest, wirst du schnell feststellen, weshalb ich immer so lachen muss wenn mir jemand erzählen will was Sinn macht und was nicht... Du wirst schnell feststellen das jedes Projekt unterschiedliche Anforderungen hat und das viele Wege nach Rom führen.

Was auf deiner statischen Portfolioseite funktioniert, funktioniert nicht zwangsläufig bei richtigen Anwendungen, also high Performance, high Security usw.

[U-Labs YouTube]

Antwort von @n4botz:
@Kmonki du willst dich hier als Entwickler mit angeblich 30 Jahren Erfahrung profilieren und bist nicht imstande auf dem Niveau eines solchen auf benannte, technische Details fundiert zu antworten? Stattdessen Whataboutism gepaart mit 08-15 Sprech wie ein Tag Informatikunterricht. Deine angeblichen 30 Jahre Erfahrungen als Entwickler sind kein beweis für technische Richtigkeit. Es gibt mehr als genügend Entwickler, deren Wissenstand in Anno Zwieback stehengeblieben ist und heute noch Mist fabrizieren.

Frameworks sind etablierter Industriestandard, sicherheitskritische Systeme nutzen geprüfte Libraries und selbst Big-Data-Stacks aus Frameworks (u.a. Java/Spring, Hibernate, Hadoop, Spark, Snowflake, Kafka samt Microservices und weiteres - je nach Stack-Wahl/Infrastruktur). Wenn du also meinst dich mit einem Autoritätsargument á la 30 Jahre Entwickler profilieren zu müssen, solltest dir wenigstens etwas mehr Mühe geben. In so gut wie allen sicherheitskritischen Bereichen und rund um Big-Data werden benannte Enterprise-Stacks eingesetzt - und teils in Eigenregie weiterentwickelt/vorangetrieben. Sei es der Einfluss von Netflix auf Spring, durch deren Microservice-Architektur und Cloud- sowie Microservice-Entwicklung im Spring-Ökosystem.

Dein selbstentwickelter RAM-Cache wird in verteilten Systemen schnell inkonsistent oder unskalierbar, weil jener pro Instanz in verteilten Systemen ohne Synchronisation schnell zu Inkonsistenzen oder Skalierungsproblemen führt. Mit guten Indizes, vernünftigen Queries und ggf. einem Cache wie Redis kann eine Datenbank 50.000 Einträge oft schon in Millisekunden durchsuchen - und du preist es hier als richtig dicke Software an. Hängt ruhig zwei gar drei weitere Nullen dran und selbst damit nichts besonderes wäre.

[DMW007]

Ihr werft viel zu viele Dinge in einen Topf. Datenbanken können ihre Daten oder Teile davon in den RAM laden. Nicht als Ersatz zur persistenten Speicherung, sondern ergänzend für bessere Leistung. Aus dem RAM holen ist schneller, als von SSDs. Um all das geht es hier allerdings gar nicht, sondern um Effizient. Wenn PHP bei jeder Anfrage zig Skripte aus dem Dateisystem in den Interpreter lädt, ist das ineffizient. Deswegen wird er in möglichst optimierter Form in den RAM geladen. Das beschleunigt auch selbst geschriebene Anwendungen ohne Zoo Drittanbieter-Abhängigkeiten. Nur möglicherweise etwas weniger. Profitieren tun sie trotzdem und darum geht es.

Nachdem der OPcache längst im Kern von PHP integriert ist, gibt es keinen Grund, den nicht zu nutzen. Viele sprechen dafür und ich habe im Beitrag/Video auch Beispiele genannt, wo es eben nicht nur um Geschwindigkeit geht.

[U-Labs YouTube]

Antwort von @christian-schubert:
Teils ein wenig fassungslos, teils aber auch belustigt verfolge ich das Chaos, das sich die Webentwicklung in den letzten eineinhalb Jahrzehnten eingebrockt hat.

Umso bemerkenswerter, dass sich auch die trendigsten Fullstack Frameworks wieder immer mehr in Richtung PHP entwickeln, jene Sprache, die ja angeblich das Allerletzte und sowieso total Pfui Gack ist.

Meine Theorie dazu ist nach wie vor, dass man krampfhaft nach einem Moat gesucht hat, um den Konkurrenzdruck flach zu halten - denn versuch heutzutage mal, mit HTML, CSS, JavaScript, PHP und Datenbankkenntnissen (von mir aus auch zusätzliche Erfahrung in Java oder Python) einen Job zu finden.

Unmöglich.

Da mag dein Lösungsansatz noch so zigmal eleganter und effizienter sein, als irgendeine Framework / Library Implementierung.

[U-Labs YouTube]

Antwort von @anonymunsichtbar3715:
PHP ist relativ simpel. Man kann definitiv viel damit anfangen, aber wenn es um großen Anwendungen mit Skalierung geht, würde ich lieber auf getrenntes Frontend und Api Backend setzen. Ist deutlich flexibler