Mein Name ist Stefan Wintermeier, hier ist meine E-Mail-Adresse, meine E-Mail-Adresse ist

hier. Auf der letzten Folie soll sie auch nochmal sein und mit ein bisschen Glück kennt sie Google auch. Erstmal vielen Dank für die Foxconn-Veranstalter und das Ticken, ist immer schön, dass wir hier noch lokal so eine Konferenz haben.

So, ich biete ConSighting rund um das Thema hochverfügbare Web-Applikationen an. Meine Kunden machen das hauptsächlich aus zwei Gründen. Der erste ist, eine schnellere Web-Applikation bedeutet, dass man eine geringere Abbruchrate hat bei den Usern, jeder kennt das, wenn eine Webseite nicht schnell agiert, dann

verliert man irgendwann die Lust und bricht ab. Der zweite Grund ist, man kann damit Server-Geld sparen, also für die Infrastruktur, wenn die Applikation an sich schneller ist, braucht man entsprechend weniger Server, ist immer ein hoher Kostenfaktor.

Das ist jetzt hier mal die interessantesten Punkte der letzten 20 Jahre. Meine ersten Web-Shop habe ich 1996 gemacht. Damals kam geradezu das Tabletech raus, war aber sehr diskutiert, von CSS noch keine

Sprache. Danach habe ich bei der SUSE das SCTS gemacht, das ist ein Trabe-Ticket-System, daraus ist dann irgendwann mal als Nachfolgeprojekt das OTS geworden. Dann kam das Gemeinschaftshaus, das war eine Telefonennlage, da war die Web-Oberfläche

auf RUBIO, erst auf PHP, das war ein ziemlich organisch gewachsenes Projekt und 2012 haben wir dann umgestellt die Web-Oberfläche auf Ruby und Rails, deswegen jetzt hier

diese Spalte auch wirklich mit neben gefüllt. Ich habe also hier so um den Dreh herum das Licht gesehen. Vorher habe ich immer gedacht, Frameworks, das kann ich alles besser. Mitte September werde ich ein Projekt veröffentlichen, ein Open-Source-Projekt,

das auf Phoenix aufbaut. Wer sich dafür interessiert, da ist mein Twitter-Händel. Ich werde heute live coden, also so wahnsinnig bin ich nicht, ich habe das alles aufgenommen, aber ich werde die Videos in Originalgeschwindigkeit abspielen.

Der Grund dafür ist, ich möchte zeigen, wie lange es dauert etwas zu machen mit den verschiedenen Sachen. Ich werde zwei Frameworks miteinander vergleichen, Ruby und Rails und Phoenix, ich möchte jedem zeigen, wie viel Aufwand das ist und an welchen Stellen man ein bisschen warten muss.

Prinzipiell habe ich nach 20 Jahren Programmierung mit Web-Abrigationen ziemlich klare Vorstellungen und weiß, was für mich wichtig ist. Erstmal die Frage nach, warum überhaupt ein Framework? Ich bin zu alt, ich muss nicht mehr das Rad neu erfinden. Im Zweifelsfall können das andere besser.

Es spart Arbeitszeit. Projekte können viel leichter up to date gehalten werden. Das ist für mich auch ein wichtiger Grund. Wir kennen das alle, ein Projekt, das wir mal angefangen haben und nach fünf Jahren weiß keiner mehr, wo was ist. Und was für Kunden ganz wichtig ist, für mich aber auch,

wir haben eine viel geringere Onboardingzeit für neue Entwickler. Wenn ich jetzt ein Ruby und Rails Projekt habe und ich habe einen neuen Ruby und Rails Entwickler und das Projekt ist sauber aufgesetzt, dann sollte der sich innerhalb kürzester Zeit zurechtfinden. Das ist einer der wichtigsten Gründe, um so etwas zu machen. Bei den Basics, die Programmiersprachen und das verwendete Framework

müssen stabil sein, sonst geht es gar nicht. Die Lizenz muss geeignet dafür sein. GPL ist an der Stelle oft ein Problem. Mir ist da MIT lieber oder BSD oder irgendwas anderes.

Die GPL ist sehr einschränkend und keine schönen Lizenz an der Stelle. Das Projekt, also die Sprache und das Framework, brauchen eine gewisse Sichtbarkeit. Ich kann nichts gebrauchen, was noch so toll ist, aber was im Rest der Welt keiner kennt.

Und ich brauche eine gewisse Menge an verfügbaren Entwicklern. Wenn ich skaliere oder wenn man das bei einem Kunden macht, wenn der Kunde will skalieren und er braucht neue Entwickler, dann nutzt das nichts, wenn das noch so eine tolle Software ist, wenn er dafür keinen Entwickler findet. Dokumentation, ein katastrophales Thema meistens.

Ein großes Problem, wenn man sich was Neues anguckt, ist die Menge. Viele, viele Open-Source-Projekte erschlagen einen mit Dokumentationen, mengenmäßig, leider qualitativ nicht so sehr. Da werden meistens irgendwelche Autoexports über die API-Schnittstelle gemacht und dann hat man da irgendwie auf einmal 1000 Webseiten.

Das nutzt da nichts. Ich habe gelernt, wenn innerhalb von einem Auto ganz am Anfang steht, it's easy, kann man das Auto meistens wegschmeißen. Weil wenn es wirklich easy wäre, dann bräuchte ich das Auto nicht. Das heißt, derjenige, der das Auto geschrieben hat, der weiß überhaupt gar nicht, wie schwer es für mich ist.

Deswegen kann er auch mich an der Stelle gar nicht abholen. Und die Entwickler von dem Framework und der Programmiersprache sind in den allermeisten Fällen schlecht im Erklären. Schwierig rüberzukriegen, aber ist nun mal so. Dann Community. Supportive Community. Die meisten Projekte haben irgendwo einen IRC.

Das ist aber für den täglichen Einsatz auch irgendwie recht unbefriedigend. Ich kann nicht beim Kundensitzen ein Problem haben und dann irgendwie mal gerade sagen, ich gehe mal gerade auf Freenode. Dann ist da keine Zeitverschiebung usw. Mainlisten sind schon mal besser, aber meistens wird man davon Informationen auch erschlagen.

Das nützt mir auch recht wenig, wenn auf eine Mainliste irgendwie am Tag 1000 Messages reinkommen. Slack ist irgendwie so der Mix aus beiden Welten. Gut für kleine Teams, für größere, irgendwie wird es auch schnell unübersichtlich. Meiner Ansicht nach ist Stack Overflow momentan so die beste Möglichkeit. Ich kann asynchron Fragen stellen und bekomme Antworten,

und die werden idealerweise von anderen direkt gradet. So, ich komme aus der Ruby-and-Rails-Schiene. Damit beschäftige ich mich jetzt seit ungefähr acht Jahren. Und möchte jetzt heute die beiden mal vergleichen.

Ruby-and-Rails und Phoenix. Ruby-and-Rails wurde von DHL geschrieben. Also geschrieben, angefangen. Es ist nicht so, dass der heute wahnsinnig viel Code produziert. Der hat Wichtigeres zu tun. Er muss Autorennen fahren und fotografieren. Mit Fotografieren habe ich echt Verständnis.

Und wir haben Chris McCord, der ist Erfinder von Phoenix. Wir sehen schon hier anhand der Zahlen Followers 179k. K steht für 1000. Und hier ist das K noch nicht da. Das heißt, die Zahl ist kleiner. Das zeigt so ein bisschen auch dieses Thema Sichtbarkeit.

Dieses Projekt, so gut wie es ist, hat noch lange nicht die Sichtbarkeit. Und das muss man sich immer vor Augen halten. Die Lernkurve von Ruby-and-Rails, das ist nicht schön am Anfang. Ich habe also auch bei Ruby-and-Rails drei Versuche am Anfang gemacht.

Bis ich dann überlegt habe, vielleicht lern ich erst mal Ruby. Und das war dann auch der Einstieg. Die Lernkurve bei Phoenix ist für so einen Steinzeitmenschen wie mich echt katastrophal. Man hat mir gesagt, die, die neu anfangen mit Programmieren, tun sich wesentlich leichter mit dem Funktionalen.

Aber ich habe schon ein paar Jahre gebraucht, um objektorientiert Programmier zu lernen. Und das jetzt irgendwie alles wieder über den Haufen zu werfen und funktional zu arbeiten, ist nicht so einfach. Jetzt stellt sich die Frage, warum wird momentan eigentlich so viel von Phoenix gesprochen in der entsprechenden Community?

Und die Antwort darauf sind immer solche Folien oder Ähnliches. Da ist oben immer etwas von zwei Millionen oder mehr und immer auf einer Hardware. Das ist ein, vereinfacht gesagt, hier ist der Blogpost dazu, vereinfacht gesagt ist das eine Chat-Applikation,

die auf einem Server läuft. Einen großen Server, aber einen Server. Und die bedient gleichzeitig zwei Millionen Clients. Also da wird die Message an zwei Millionen Clients rausgepusht. Und das ist eine ziemliche Leistung.

Das ist einer der Kunden, also Phoenix läuft auf Elixir als Programmiersprache. Elixir baut auf Erlang auf. Erlang wird zum Beispiel auch von WhatsApp benutzt. Nur so kann die das überhaupt realisieren in der Geschwindigkeit. Das Problem, was ich nur dabei habe, ist, ich brauche kein Chat-Client bei den meisten meiner Kunden.

Denen ist das relativ wurscht. Die zwei Millionen Concord-User, den Kunden suche ich noch auf einem System. Deswegen möchte ich jetzt mal ein Beispiel machen.

Rates versus Phoenix Shootout mit einer Applikation, die ein bisschen mehr an der Realität dran ist. Ich habe jetzt hier ein Adressbuch mit einem User, also mit Usern und E-Mail-Adressen. Was jetzt hier interessant ist, ich habe hier in der Datenbank ein Geburtsdatum.

Daraus wird hier die Distanz zum heutigen Zeitpunkt errechnet, vorgestern war das. Aber hoffen wir mal, dass jetzt keiner Geburtstag hat heute. Das sind die E-Mail-Adressen, die sind in einer 1 zu N verknüpfen in der Datenbank. Und hier ist das Rubian Rates und das hier ist Phoenix.

Erkennt man an den Ports, Rubian Rates sind Port 3000 in der Development-Umgebung, Phoenix 4000. Das Layout hier ist ein bisschen anders, die nehmen hier per die Fortune immer Bootstrap mit rein. Das ist aber jetzt erstmal wurscht. Die Daten sind identisch, ich benutze die gleiche Datenbank.

So, der Code wird in Echtzeit geschrieben. Wie gesagt, ich habe das Video aufgenommen und möchte damit zeigen, wie lange etwas dauert. Fangen wir mit Rubian Rates an. Wir setzen als erstes mal die Applikation auf. Dazu sehe ich das Verzeichnis an.

Ich wollte das Video schneller machen, aber damit wäre es wieder... Ich versuche ein bisschen schneller zu tippen. Hier wird die Datenbank angelegt, also mit dem MySQL-Scheiter. Ansonsten per die Ford geht immer davon aus, dass man SQLite 3 benutzt.

Das nützt mir nichts, weil ich dafür keine gute Anbindung bei Phoenix habe. Jetzt sieht man hier, dass das, was bei Rubian Rates relativ lange dauert, die ganzen Gems einzubinden.

So, jetzt habe ich die Applikation hier in dem Verzeichnis drin. Das ist mein Grundgerüst, da starte ich. Jetzt konfigure ich die Datenbank, in der stelle ich die Tabellen. Dazu gehe ich in die Datei-Contact-Database-Yaml. Gehe jetzt runter in den Development-Bereich hier und ende jetzt hier Address Book Development to Address Book Dev.

Das mache ich deshalb, weil das der Default für Phoenix ist. Dann kann ich nachher leichter von Phoenix auf die gleiche Datenbank zugreifen. Jetzt mache ich hier in Rates.db.create, damit wird die Datenbank angelegt. Als nächstes wird dann Scaffold angelegt für Users und E-Mail-Adressen

mit dieser Has-Many-1-zu-end-Verknüpfung. Scaffold ist der Mechanismus bei beiden Projekten, um einem die ganze Grundarbeit schon mal wegzunehmen. Das heißt, die Modelle werden angelegt, die Controller werden angelegt, die Views werden angelegt.

Man hat die Applikation so, wie ich sie eben gezeigt habe. Das ist jetzt hier das Scaffold für die E-Mail-Adressen. Da kann ich jetzt hier direkt sagen, User sind als Referenz da. Dann wird schon die Belongstour-Verknüpfung im Modell eingetragen. So, mit dem Faker-Gam erstelle ich jetzt 50 Beispiel-User mit jeweils zwei E-Mail-Adressen.

Um die Datenbank zu verfüllen, benutze ich das Faker-Gam, weil es einfach am schnellsten geht. Dazu muss ich das Gamm einbinden, danach einen Bundle starten. Und jetzt befülle ich die DB-Seats.

Das ist ein Mechanismus bei Rails, mit dem ich Datenbanken initial befüllen kann. Und hier ist der Beispiel-Code dafür. Das ist einfach eine Sub-Scheife, die 50 mal durchgegangen wird, wenn die Einträge erfüllt. Und jetzt wird das aufgerufen mit Rails-DB-Seat.

So, im Controller wird jetzt die Instance-Variabe add-users so gesetzt, dass da alle User drin sind in der Tabelle, aus der Tabelle. Und die dazugehörigen E-Mail-Adressen werden per Include mit direkt geladen. Das heißt, dass ich später nicht mehrere, mehr oder weniger auf die Datenbank zugreifen muss.

Das ist der Controller. Das hier ist der Vifort aus dem Scarfhold. Und dann traue ich einfach Includes Doppelpunkt E-Mail-Adresses ein. So, im Index-View, das ist das, was man nachher sieht, das ist das, was das HTML generiert,

werden jetzt alle User aufgelistet in der Tabelle mit den entsprechenden Seiten und der Liste der E-Mail-Adressen. Dazu rufe ich jetzt in dem Verzeichnis-App, da habe ich mich vertippt. Da habe ich gedacht, ich wäre bei Phoenix-Views-Users-Index auf. Das ist jetzt das HTML für die entsprechende Seite.

Da wird jetzt gerade der Heller neu geschrieben, also der Tabellen-Heller. Und darunter kommt jetzt gleich der Code, mit dem das ausgefüllt wird.

Bei Rails habe ich den Vorteil, dieses Distance of Time and Words ist schon mit eingebaut. Das kann ich so aufrufen.

Bei Phoenix muss ich das selber mit einbauen. Und jetzt mache ich die Schleife, wo die E-Mail-Adressen mit eingetragen werden.

So, jetzt starte ich den Rails-Server und rufe die Well-Users-Index in Prosa auf.

Erstmal die Hauptseite und jetzt oben noch die Users.

So, das ist jetzt die Ansicht von den 50 Usern. Das ist jetzt hier wieder das Log vom Server. Und das zeigt mir an, diese Abfrage hat initial 1.265 Millisekunden gebraucht. Jetzt mache ich drei Results, um zu zeigen, wie lange es bei folgenden Aufrufen dauern würde.

Durcherweise geht das schneller. So, das sind die Zeiten. Der erste Zugriff bis zu einer Sekunde und dann immer so ungefähr im 100 Millisekunden-Bereich.

Das sind jetzt unsere Vergleichszahlen. Jetzt machen wir Phoenix in der Version 1.2, eben das war Rails 5.0 die aktuelle Version. Die Applikation aufsetzen.

Ich meine Unterverzeichnis für Phoenix und dann sage ich mit Mix, Phoenix, New und den Applikationsnamen, dass ich ein neues Framework, also nicht ein neues Framework, neue Applikation haben will.

Und auch da sage ich ihm wieder, dass ich das Ganze mit einer MySQL-Datenbank verknüpfen möchte. Das kann ich auch alles von Hand nachher machen, aber wenn ich es an der Stelle mache, geht es einfach schneller. Und jetzt hier, was uns eben bei Bande so viel Zeit gekostet hat, das kostet uns jetzt hier die Zeit bei NPM installen.

Da ist momentan auch leider kein Weg drum herum. Ich stolpern da jeden zweiten Tag über irgendwas anderes.

Es gibt nichts Perfektes. Das Problem bei den Gems ist, dass sehr viele Gems einfach nicht gepflegt werden. Und so, jetzt habe ich die Applikation, die Phoenix-Applikation erstellt.

Und jetzt sehe ich das Scaffold für die User und die E-Mail-Adressen an. Die Datenbank existiert bereits, die habe ich hier eben befüllt, die benutzen wir wieder. Aber das Scaffold muss ich jetzt anlegen. Hier ist logischerweise eine andere Syntax, aber die gleiche Grundidee.

Jetzt mache ich das Gleiche für die E-Mail-Adressen. Und das geht dann deutlich schneller durch. Hier sieht man übrigens, das ist etwas, was Red automatisch macht.

Phoenix sagt, lass das lieber den Menschen machen. Ist am Anfang ein bisschen gewöhnungsbedürftig, macht aber mittelfristig tatsächlich mehr Sinn. So, jetzt müssen wir die 1 zu N-Verknüpfung zwischen den User und den E-Mail-Adressen konfigurieren.

Und wir müssen das Created-Ad und das Inserted-Ad ummappen. Also Rails benutzt per Default Created-Ad und Updated-Ad, um in einem Datenbank-Eintrag zu zeigen, wann etwas erstellt und wann etwas abgedatet wurde.

Phoenix benutzt per Default Inserted-Ad und Updated-Ad. Keine Ahnung warum, ist einfach so. Damit ich auf die gleiche Datenbank zugreifen kann, muss ich das hier entsprechend eintragen.

Das Gleiche mache ich jetzt nochmal bei den E-Mail-Adressen.

Jetzt müssen die Routen eingetragen werden. Das ist auch anders als bei Rails. Bei Rails werden die Default-Routen schon direkt automatisch mit eingetragen. Bei Phoenix nicht, da muss ich die Routen separat eingetragen. Das wird übrigens auch hier vom Skript angezeigt. Jetzt gehe ich in die entsprechende Datei dafür und trage die Routen ein.

Dann muss ich im Controller noch eingeben oder konfigurieren, programmieren ist das richtige Wort, dass die dazugehauen E-Mail-Adressen direkt mitgedaten werden. Bei Rails ist es so, da würde es sogar funktionieren ohne das Includes. Aber es wäre deutlich langsamer, weil der bei jedem Aufruf in der Datenbank nachfragen würde,

ich habe den User, welche E-Mail-Adressen hat der. Mit dem Includes macht er das direkt initial einmalig für alle in der Curry drin. Bei Phoenix ist es so, wenn ich das hier nicht machen würde, würde die View überhaupt nicht funktionieren. Weil Acto, das ist das Gegenstück zu Active Record, nicht diese Logik drin hat.

Ich muss also sagen, lag die bitte mit. Dann, da ich nicht diesen Time-Ago-Inverse-Helper habe, muss ich den auch noch installieren. Dazu gibt es hier in der mix.exe die Möglichkeit, solche Tools mit einzubauen und die werden nachher geladen.

Das kann man ungefähr vergleichen mit dem Bundler. Ungefähr.

Nachdem ich das hier konfiguriert habe, muss ich dann das Ganze mit mix.debs.get starten. Das ist das Gegenstück zu Bundle.

Jetzt muss ich den entsprechenden Helper natürlich noch einbinden. Das kann ich für diesen entsprechenden View in der Datei machen, also Users View. Es wird bei Phoenix immer nur implizit gearbeitet, nicht per Default auf alles.

Wenn ich das habe, dann kann ich die Anpassung im User-Index-Templates-Fall machen. Da sieht man jetzt, dass die Syntax logischerweise ein bisschen anders ist, aber zumindest vom Lesen her ist es recht einfach.

Vom Schreiben her muss man sich tatsächlich umgewöhnen. Sieht dort nicht einfacher aus, als es ist.

Hier muss ich zum Beispiel über Acto-Date-Time-From-Date aus dem Geburtsdag, was ein Datum ist, ein Date-Time machen, weil das Time-Ago in Words nur Zeiten akzeptiert und keine Daten. Unten ist jetzt die Syntax, wie ich durch die ganzen E-Mail-Adressen lügen kann.

Wenn Sie sich für Phoenix und für LXC interessiert, es gibt momentan eigentlich nur zwei Bücher dazu von Pragmatic Bookshelf.

Das eine von Dave Thomas zum Thema LXC und das andere von den Entwicklern von Phoenix zu Phoenix. Ich finde beide nicht so richtig prickelnd, aber es gibt keine Alternative.

Nachdem wir das gemacht haben, können wir jetzt den Phoenix-Server starten und auch wieder im Browser die Seite aufrufen. Jetzt sehen wir hier links die Anzeigen des Stockfiles.

Das ist der erste Aufruf gewesen, der geht in Phoenix in 120 ms, also deutlich schneller. Ich könnte jetzt übrigens diesen Code hier verändern und neu deployen, ohne die Applikation anzuhalten.

Das kann ich mit Rates überhaupt nicht, also Rates mile weit von entfernt. Das ist wirklich ausgelegt für sehr große Installationen mit minimaler Downtime. Jetzt mache ich das Gleiche mit den Mehrmals-Reloaden. Auch da wieder die folgenden Reloads sind alle schneller.

So, jetzt wird es spannend. Das sind die Zeiten im Vergleich. Jetzt wird ziemlich schnell klar, woher der Bohai um Phoenix kommt.

Das sind Zeiten, da können wir in der Rates-Welt nur von träumen. Jetzt wird jeder sagen, ja, aber was ist mit Caching?

Beides ein Development, leichter ein Nachteil für beide Systeme. Ich habe mir tatsächlich um die Frage natürlich auch im Vorfeld Gedanken gemacht, was führe ich jetzt hier vor. Für den Fall ist es einfacher, wenn ich das Development-Doc habe, weil ich da alle Zeiten mit angezeigt bekomme. Im Production-Doc ist es nicht so, dass Rates irgendwie schneller ist.

Also der Vergleich stimmt, die Zeiten sind natürlich für beide noch ein bisschen besser. Jetzt würde jeder sagen, ja, was ist mit Caching? Ich verdiene mit Caching einen Großteil meines Geldes, deswegen ist das ein Thema, was mir sehr am Herzen liegt. Ich habe jetzt hier meinen Russian-Doll-Caching eingebaut für diesen View in Rates.

Also einmal eine Klammer um die gesamte Tabelle und dann um jede Zeile. Das wird dann im Cache abgelegt. Als Cache habe ich jetzt hier den normalen default für Development-Cache genommen. Der Speicher ist einfach im Speicher drin, also unter Development.

In der normalen Welt, also in der Produktion, nimmt man dann meistens Memcache. Faktisch ist das langsamer, aber für die Größe dann wieder schneller. Plus die Netzwerk-Latenz, weil man dann meistens einen Server nimmt für mehrere Rates-Server. Die Zahlen hier sind Beispielzahlen.

Also man darf sich jetzt nicht auf die Millisekunde hin und her verlassen. Hier zum Beispiel sieht man, der Physiker würde sagen, das ist ein Messfehler. Weil diese Zeit kann unmöglich geringer sein als diese Zeit. Denn, wenn ich den Cache initial schreibe, dann brauche ich halt mehr Zeit.

Denn ich muss den Cache schreiben. Das habe ich ja hier überhaupt gar nicht gehabt. Da habe ich noch nicht mal den Cache-Key ausgerechnet. An der Stelle war es einfach so, die Videos hatte ich hier schon fertig gemacht. Wie ich dann mit dem hier fertig war und habe diese Folie erstellt, habe ich gedacht, neu machen, das hätte so lange gedauert und wäre auch unehrlich gewesen.

Also das ist ein ganz gutes Beispiel dafür, wie groß die Varianzen sind im Messen. Man muss da immer eine große Menge nehmen und das auch immer mit klarem Menschenverstand analysieren. Wir sehen aber, dass die Zahlen hier immer noch dramatisch zum Vorteil von Phoenix sind.

Also ich habe hier unten, wenn ich schon den Cache geschrieben habe, also nur noch lese, bin ich mindestens doppelt so schnell. Und hier oben ist es halt ein Vielfaches. Deswegen macht man sich bei Phoenix um Caching keinen Kopf,

weil das Problem ist an der Stelle nicht so dramatisch wie bei Raids. Probleme beim Caching? Der erste Zugriff ist immer langsamer, der Cache muss ja initial geschrieben werden. Ich muss einen zusätzlichen Cache-Server einplanen, also mindestens mal einen. Caching ist aufwendig und fehleranfällig, also Cache-Keys, das ist ein Thema, was nicht trivial ist.

Vor allem, weil die meisten Web-Applikationen nicht so einfach sind wie jetzt hier dieses Adressbuch. So, jetzt versuche ich das beides mal wieder zu vergleichen, indem ich Datensätze lösche. Das heißt, ich lösche erst, ich starte jetzt erst beide Server, den Rail-Server und dann den Phoenix-Server.

Jetzt habe ich da die entsprechenden Applikationen immer und hier sehe ich die Logs. Also hier bin ich ungefähr bei 700 Millisekunden, hier jetzt bei 200 Millisekunden.

Und jetzt mache ich einen Reload, 27 Millisekunden, 24 Millisekunden. Und jetzt fange ich an einzelne Datensätze zu löschen, um zu sehen, also über die Web-Applikation zu löschen, um zu sehen, wie lange das dauert und was da passiert.

Ich habe die Zeilen gleich nochmal in der Tabelle aufgeschrieben. Hier sieht man übrigens ganz gut, das war schon Doral-Caching. Der äußere Cache merkt, dass er nicht mehr funktioniert, weil ein Datensatz weg ist.

Deswegen wird der Cache nochmal neu geschrieben und dafür die ganzen kleinen Dorals quasi eingesammelt. So, das Ganze sieht denn so aus. Beim ersten Zugriff habe ich 7 mal 70 Millisekunden, 29 und so weiter.

Jetzt löschen in Phoenix kostet mich 75 Millisekunden bei Rails und 28 Millisekunden bei Phoenix. Ich habe aus der Phoenix-Applikation gelöscht und bin damit schneller als die Rails-Applikation, die gar nichts gemacht hat.

Und unten ist das Gegenteil. Und jetzt kommt was, was problematisch ist, wenn man Rails einsetzt. Ich lösche jetzt mal eine E-Mail-Adresse mit Phoenix.

Die E-Mail-Adresse ist jetzt gelöscht, ich gehe jetzt wieder auf den User-Index-View und wir sehen hier unten, die E-Mail-Adresse ist weg. Ich bin nur noch eine angezeigt. Ich habe hier oben auf Reload gedrückt mehrmals. Wir sehen, die E-Mail-Adresse ist da noch da, obwohl er auf die gleiche Datenbank zugreift.

Das ist das Problem bei Rails durch das Caching. Ich muss dann in der Rails-Welt bleiben, weil Rails hat überhaupt gar nicht mitbekommen, dass ich in der Datenbank etwas geändert habe. Hätte ich das gleiche andersrum gemacht, würde das funktionieren. Also ich kann in Rails etwas löschen und Phoenix bekommt das mit, weil Phoenix immer die Datenbank abfragt.

Belongs to Touch True, korrekt. Aber dazu muss ich denn in der Welt bleiben. Das war jetzt ein abstrakteres Beispiel für den Fall, dass auf die Datenbank eine andere Abdigation zugreift, die nichts mit Rails zu tun hat.

Das habe ich bei relativ vielen Szenarien. Und dann muss ich über Active Record gehen, was relativ langsam ist. Ich muss dran denken einfach. So, das Ergebnis ist gut aus. Die Entwicklungsgeschwindigkeit ist ungefähr gleich.

Klar, wenn ich damit neu anfange, dann brauche ich immer länger. Aber ob ich jetzt der Rails-Entwickler bin oder der Phoenix-Entwickler, ich habe von der Entwicklungsgeschwindigkeit her kein Vor- und kein Nachteil. Phoenix ist immer schneller als Rails. Beim ersten Zugriff sehr viel schneller. Wenn es um eine Abdigation geht, die nicht leicht cashbar ist oder gar nicht cashbar ist,

habe ich immer einen klaren Vorteil bei Phoenix. Rails kann bei Mehrfragen lesen vom nicht geänderten Daten mit Caching-Bodengut machen. Dazu muss es aber alleine geherrschende Daten sein. Oder man muss immer darauf achten, dass die Daten getouched werden. Was für Abdigation außerhalb von der Rails-Welt nicht immer einfach ist.

Noch ein paar allgemeine Punkte. Die Ökosysteme, was für mich immer ein wichtiger Punkt ist für so ein Framework. Bei Rails gibt es sehr viele Gems. Wir hatten eben schon mal kurz die Diskussion dazu. Das Problem dabei ist immer, dass die Leute sehr schnell die Lust an selbstgeschriebenen Gems verlieren

und dann nicht up to date halten. Also ein Gem, was ich heute suche, gucke ich mir immer an. Anhand von Komplexität und wenn es ein einfaches Gem ist, programmiere ich es fast immer selber neu. Weil ich dann sicher sein kann, dass es auch in Zukunft funktioniert in meinem Code.

Bei Phoenix gibt es einen großen Fundus an fertigen Elixier- und Erdangbausteinen. Aber das Ökosystem bei Rails ist komplexer, eben positiver. Der nächste Punkt, Mitarbeiter, bezahlt oder unbezahlt.

Bei Ruby on Rails ist es schon sehr, sehr schwierig in Deutschland jemanden zu finden. Also wer einen Job sucht, soll Ruby on Rails werden und dann fiesst Milch und Honig. Bei Phoenix sieht es richtig schlecht aus.

Also da gibt es ganz, ganz wenige Entwickler zu. Glücklicherweise gibt es noch ganz wenige Anfragen dazu. Also da ist es nicht so dramatisch. Und wer hier Rails entwickelt und einen neuen Job sucht, der soll mir bitte eine E-Mail schreiben. Ich habe nämlich Kunden, die mir Provision dafür geben, wenn ich Sorte vermittel.

Das ist mal so eine subjektive Bewertungsmatrix. Phoenix ist ganz klar Geschwindigkeit, Geschwindigkeit, Geschwindigkeit. Ich habe diese Websocket-Geschichte. Wenn ich sowas brauche, dann ist das ein No-brainer, dann muss ich da drauf gehen. Rails hat jetzt mit 5 auch Action-Cable. Das ist aber nicht so schnell, das ist nicht so stabil.

Das ist ein bisschen so, man hat so ein bisschen das Gefühl, Phoenix hatte es erst und Rails ist nachgezogen, ist aber irgendwo auf der halben Strecke stehen geblieben. Das wird von der Performance her nie in die Region kommen, wie Phoenix es hat.

Das Ökosystem ist bei Ruby und Rails besser. Die Dokumentation ist da auch besser. Nicht jetzt vom Projekt, aber es gibt einfach mehr Literatur drumherum. Es gibt mehr Blogs, es gibt mehr Bücher. Das habe ich bei Phoenix noch nicht. Die Mitarbeitersuche ist bei beiden schwierig, aber bei Phoenix katastrophal.

Deswegen, für die typisch deutsche Firma ist Ruby und Rails heute sicherlich der bessere Startpunkt. Wenn ich maximale Performance brauche, dann komme ich um Phoenix aber nicht drumherum.

Das war's. Vielen Dank für die Aufmerksamkeit. Wie schon gesagt, ich habe ein Open Source Projekt, was ich jetzt nicht vorstellen konnte, was nicht in den Rahmen des Vortrages passt. Das werde ich im September veröffentlichen. Wer sich dafür interessiert, möchte bitte meinen Twitter-Kanal abonnieren. Hier unten ist noch mal meine E-Mail-Adresse.

Wenn im Nachgang von einem Vortrag noch irgendwelche Fragen einfallen, so etwas passiert ja meistens auf dem Weg nach Hause, mir ruhig eine E-Mail schreiben und mir ein bisschen Zeit geben zum Antworten. Aber ich bemühe mich eigentlich alles immer zügig zu beantworten. Ansonsten, wenn jetzt noch Fragen sind, freue ich mich auch. Vielen Dank.