Coden, aber effizient!

Wir leben im digitalen Zeitalter (na gut, die meisten von uns), und langsam aber sicher wird vielen Entscheidern klar, dass die AWS-Cloud (oder ihre Verwandten) nicht nur total praktisch ist, sondern auch eine ganze Menge Energie verbraucht. Schätzungen sprechen von bis zu 20% des Energieverbrauchs der ganzen Welt. Wohlgemerkt sind Anwendungen in der Cloud immer noch sparsamer als eigene Rechenzentren mit Servern aus Blech, die 24 Stunden an der Steckdose nuckeln, aber beispielsweise nur tagsüber benötigt werden. Cloud-Instanzen sind üblicherweise “shared” und verbrauchen nur dann Energie, wenn benötigt. Trotzdem bedeuten mehr Cloud-Instanzen natürlich auch mehr Energieverbrauch (und CO2-Ausstoß, sofern das Rechenzentrum keinen grünen Stromanschluss besitzt).

Tatsächlich können wir die Frage nach dem Energieverbrauch auch Codern und Software-Architekten stellen: Benötigt euer Software-System wirklich 10 Instanzen und 3 Datenbanken? Muss für eine eher simple Anwendung 1 GB RAM reserviert werden und die Kiste mit dem fettesten Prozessor oder darf es ein bisschen weniger sein? Sollte der Energieverbrauch einer Plattform vielleicht sogar zu den Entscheidungskriterien gehören?

Der Vergleich

Für die 2. Auflage meines Buchs “Besser coden” habe ich ein Kapitel über effizienten Code geschrieben – und ein paar Messungen durchgeführt. Dazu habe ich eine relativ einfache Webanwendung in mehreren Sprachen geschrieben und Aspekte wie Performance, Ressourcenverbrauch und Anspruch an Entwickler verglichen. Letzteres ist nicht zu unterschätzen: Spart eine Technologie Speicher, aber Sie finden keinen Entwickler, der sie beherrscht, bleibt ihr tolles Softwaresystem graue Theorie.

Es traten an:

  • Java 13 und Spring Boot, das beliebte Framework für Webservices
  • PHP 7.4, eine bewährte, einfache Skriptsprache mit Cache APCu
  • Rust 1.52 und Actix Web, eine ziemlich neue Sprache samt passendem Webservice-Framework
  • sowie quasi als Online-Bonus (nicht im Buch) Go.

Der Webservice besitzt nur einen einzigen Endpoint, der dafür gedacht ist, ein Wort gegen eine hinterlegte Liste zu prüfen. Eine solche Funktion ist beispielsweise in einem Scrabble-Spiel nötig: Ist das gelegte Wort erlaubt oder nicht? Das Ergebnis wird dabei als JSON-Antwort formuliert.

Die Liste ist absichtlich nicht in einem ausgewachsenen Datenbanksystem hinterlegt, denn ich möchte nicht die Effizienz unterschiedlicher RDBMS bewerten, sondern die von Software-Plattformen. Daher lädt die zu schreibende Anwendung die Wortliste beim Start aus Textdateien und hält sie dann im RAM. Im Test enthielt diese Liste knapp 180.000 Einträge. Im Fall von PHP erfordert eine solche Vorgehensweise zwingend den Einsatz eines Caches (hier verwendet: APCu), um die Dateien nicht bei jedem Aufruf des Skripts erneut laden zu müssen.

Die Rechenzeit habe ich mit dem Apache Benchmark ab gemessen, einmal einen Einzelrequest und einmal 10.000 auf einmal in sechs parallelen Threads, um die Leistung im Parallel Processing zu bestimmen.

Den Code finden Sie in Grundzügen in meinem Buch (bis auf die Go-Version). Hier fasse ich Ihnen nur die Ergebnisse zusammen:

Java/Spring BootPHP/APCuRust/ActixGo
RAM-Verbrauch50 MB200 MB0,9 MB24 MB
Anwendungsgröße19 MB (JAR)372 Bytes (Skript)8,4 MB (binär)7,1 MB (binär)
Zeit 1 Aufruf1,8 ms0,9 ms0,4 ms0,5 ms
Zeit 10.000 Aufrufe1,1 s0,6 s0,5 s0,5 s
Startup-Dauer2,5 snicht messbar53 ms75 ms
Buildtime7,4 sentfällt69 s1 s
Coding-Anspruchleichtsehr leichtschwierigmittel

Sie sehen, dass das rein binäre Rust-Programm zur Laufzeit am schnellsten und genügsamsten ist – aber finden Sie mal einen Rust-Entwickler auf dem Jobmarkt oder lernen Sie die Sprache “mal eben”! Ich hab letzteres versucht und brauchte mehrere Packungen Schokokekse, um die spezielle Speicherverwaltung zu kapieren. Die lange Buildtime ist dabei dem anspruchsvollen Compiler- und Linker-Vorgang geschuldet.

Abgesehen vom RAM-Verbrauch ist PHP unter dem Strich wohl die effizienteste Lösung. Aber viele Entwickler scheuen sich davor, größere Projekte in PHP anzulegen – die fehlende starke Typisierung und die immer über uns Entwicklern schwebende Versuchung, spaghettimäßig PHP- und HTML-Code zu mixen, sowie ein paar Fallen wie vergessenes $this->, sind klare Minuspunkte. Dafür ist die Turnaround-Zeit Null: Skript nur speichern, schon ist es bereit zum Aufruf per HTTP.

Java ist nicht ohne Grund sehr beliebt. Aber die Java-Runtime, so optimiert sie mittlerweile auch ist, geht alles andere als sparsam mit Ressourcen um und ist merklich langsamer als die Binärcode-Konkurrenz (auch PHP verwendet dank Zend-Engine letztlich Binärcode). Ein Maven-Buildprozess lädt gefühlt mehrmals täglich das halbe Internet runter. Dafür ist der Code (speziell mit Spring Boot) aufgeräumt und vergleichsweise leicht zu debuggen. Große Projekte mit komplexer Geschäftslogik sind in Java wohl vergleichsweise am lesbarsten abzubilden.

Fazit

Sie sehen: Es gibt keine Lösung, die gleichzeitig einfach und technisch effizient ist. Sie müssen immer abwägen: Lohnt es sich, in eine hocheffiziente, moderne Technik wie Rust oder Go zu investieren? Oder setzen Sie auf eine bewährte und
einfache Technik wie Java und nehmen in Kauf, dass Sie mehr
Server benötigen (und Energie verbrauchen), wenn mehr Rechenpower erforderlich ist? Gerade bei neuen Projekten ist es sicher eine gute Idee, über diese Fragen zu diskutieren. Denn später können Sie die Plattform nicht mehr einfach ändern.

So bleiben vermutlich noch auf Jahre oder Jahrzehnte Java-Webservices
und PHP-Skripte state of the art – obwohl mit Rust oder Go, C++20, D …
technisch hochmoderne und extrem effiziente Konkurrenzprodukte be-
reitstehen.

Mein Dank für die Mitarbeit geht an Marcus Schlechter.

Wie Spaghetti ist PHP?

Wer kennt sie nicht, die Sprache von WordPress? Laut Statistiken laufen um die 30% aller Webseiten (auch diese) auf WordPress – und damit mit der 25 Jahre alten Skriptsprache PHP (freilich vermixt mit einer gehörigen Portion HTML, Javascript und CSS). Also nicht Java, nicht C# … sondern PHP. Insgesamt kommt PHP sogar auf einen Anteil von 79% aller Webseiten, deren verwendete Plattform bekannt ist, behauptet W3Techs.

PHP – eine Sprache, die Spaghetticode geradezu herbeisehnt, denn damit können sogar Anfänger innerhalb von Sekunden dynamische Webseiten schreiben, mit Datenbank-Anbindung, Formular-Sanitychecks und haufenweise Sicherheitslücken.

Nun ja, die Situation hat sich gebessert, seit URL-Parameter nicht mehr automatisch als Variablen wie $param zur Verfügung stehen – trotzdem verleitet die Natur der Sprache zur Beimischung von HTML wie hier:

foreach($angebote as $angebot) { print "<div>$angebot</div>";}

Ups, heute leider keine Angebote:

Na ja. Kann ja mal passieren.

Hinweisen wollte ich hier eigentlich nicht auf schlechte Fehlerbehandlung, sondern auf etwas anderes: HTML-Code in String-Literalen ist aus Sicht der Entwicklungsumgebung meist irgendein Text. Folglich findet darin keine Validierung statt. Ein versehentlicher, unbemerkter Tastendruck innerhalb des Strings kann die Darstellung der Webseite komplett zerschießen, ohne dass Sie, Ihre Entwicklungsumgebung oder PHP es bemerken (klar gibt es Unit-Tests für PHP, aber ich fürchte, allzu verbreitet sind die nicht). Dass man dergleichen mit einer Template-Engine umgehen kann, die HTML- und PHP-Code in getrennten Dateien verwaltet, dürfte den meisten Lesern klar sein – aber das ist natürlich viel umständlicher und nicht so schnell fertig.

Mit strukturierter (also aufwändigerer, zukunftssicherer) Programmierung ernten Sie als Früchte eine ganze Reihe Vorteile von PHP:

  • Minimaler Footprint auf dem Server (ein paar Textdateien, nicht megabyteweise Java-Libs)
  • Hohe Performance (dank Codecache und bei schlauer Programmierung, siehe dazu weiter unten)
  • Turnaround-Zeit ist 0 (Zeit zwischen Speichern einer PHP-Datei und HTTP-Aufruf gegen localhost zum Testen)
  • Und nicht zu vergessen: Hohe Verbreitung in der Community, also ist es leicht, Unterstützung zu finden.

Fairerweise seien ein paar Nachteile genannt:

  • Vergleichsweise hoher RAM-Bedarf
  • Keine strenge Typisierung
  • Objektorientierte Programmierung leicht nervig (ich vergesse dauernd das $this->, Sie auch?)
  • Verleitet zu unsauberer Programmierung durch globale Variablen, prozedurales Coden und verschachtelte includes
  • Größere Updates erforderten in der Vergangenheit größere Umbauten (z.B. MySQL-Funktionen), so dass viele Webseiten nie upgedated wurden, weil der Aufwand nicht lohnt → eine solche radikale Update-Policy führt dazu, dass viele Nutzer ihre Systeme nicht updaten und damit Sicherheitslücken bestehen bleiben

Zur oben erwähnten “schlauen Programmierung” ein kleiner Info-Drops: Im Gegensatz zu einer Java-Anwendung, die einmal hochfahren muss, ist ein PHP-Skript zunächst einmal “stateless”, es kennt also keine globalen Daten bzw. muss sich alles selbst zusammensuchen, was es braucht. “Weniger schlaue” Programmierung würde hier bedeuten, etwaige benötigte Daten beim Start des Skripts aus Dateien oder Datenbank nachzuladen. Bei jedem Start des Skripts. Das ist natürlich ineffizient. Stattdessen können Sie den In-Memory-Cache APCU verwenden, der wie ein Key-Value-Store im RAM funktioniert und daher extrem performant ist und im Gegensatz zum ebenfalls bewährten Memcached keine externe Komponente benötigt. Wir versuchen also mal im folgenden Beispiel beim Start des Skripts, einen benötigten Wert ($words) aus dem Cache zu holen. Sollte er fehlen (also beim allerersten Start), laden wir ihn aus irgendwelchen Dateien und speichern ihn im Cache:

if(apcu_exists("words")) { 
  $words=apcu_fetch("words");
} else { 
  $words = load_words_from_file("irgendwelche_woerter.txt");
  apcu_add("words",$words);
}
// es folgt der Code, der $words benötigt

Der Performancegewinn ist erheblich, wovon Sie sich leicht selbst überzeugen können, wenn Sie Test-Requests auf ein solches Beispiel loslassen. Um auch mal mehrere Requests auf einmal abzufeuern, können Sie übrigens den Apache Benchmark ab verwenden, etwa so:

ab -c 6 -n 10000 http://localhost/test.php?input=Hurra

Mit den gezeigten Parametern führt ab 10.000 Requests gegen die übergebene Adresse aus, und zwar in 6 parallelen Threads (seien Sie fair und überlassen Sie PHP/Apache auch ein paar, meine Maschine hat 12 Kerne, daher Fifty-Fifty). Das Tool gibt dann eine ausführliche Statistik über die Performancemessung aus:

Concurrency Level: 6
Time taken for tests: 0.629 seconds
Complete requests: 10000
Failed requests: 0
Non-2xx responses: 10000
Total transferred: 1850000 bytes
HTML transferred: 0 bytes
Requests per second: 15901.99 #/sec
Time per request: 0.377 ms
Time per request: 0.063 [ms] (mean, across all concurrent requests)
Transfer rate: 2872.92 [Kbytes/sec] received

Sie sehen: Ja, auch in PHP kann man strukturiert, effizient und sauber programmieren – aber PHP zwingt Sie nicht zu Disziplin, das müssen Sie schon selber tun. Empfehlenswert sind daher z.B. im Team knackige Code-Reviews und zielführende Mikroarchitektur-Debatten, um für porentief reinen Programmierstil zu sorgen.

tl;dr: PHP ist schnell und effizient, aber passen Sie auf, dass Sie keinen Spaghettisalat produzieren.