Das Backend von Meta Threads wurde mit Python 3.10 aufgebaut

 (twitter.com/llanga)
2 Punkte von GN⁺ 2023-07-07 | 1 Kommentare | Auf WhatsApp teilen

„Wussten Sie, dass das Backend von #MetaThreads mit #Python 3.10 aufgebaut wurde?

Es läuft auf dem #Cinder-Fork von Instagram, und dieser Fork enthält mehrere interessante Funktionen, die sich von normalem Python 3.10 unterscheiden, darunter ein JIT-Compiler, Module mit Lazy Loading und vorcompilierte statische Module.“

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-07
Meinungen auf Hacker News

  • Für die Fraktion „Python ist für Production-Backends nicht schnell genug“ ist das ziemlich ironisch. Schließlich hat dieselbe Firma das größte soziale Netzwerk betrieben, das mit PHP + MySQL gebaut wurde

    • Technisch stimmt das, aber schon lange wurde dort kein reines PHP mehr unverändert ausgeführt. Mit HHVM JIT wurde es in x86-Code umgewandelt und nativ auf den Maschinen ausgeführt, außerdem steckte sehr viel Optimierung darin
      Auch die virtuelle Maschine, die den JIT ausführt, ist komplett in C++ geschrieben, und die MySQL-Distribution ist ebenfalls ein stark modifizierter interner Fork für Skalierbarkeit. Darin stecken Dinge wie Trennung von Storage und Compute, Sharding, eine RocksDB-basierte Storage Engine statt InnoDB und Raft für synchrone Replikation
      Um die Backend-Infrastruktur skalierbar zu machen, ist wirklich hervorragendes Engineering eingeflossen
      Lesenswerte Materialien:
      [1] https://engineering.fb.com/2016/08/31/core-data/myrocks-a-sp...
      [2] https://research.facebook.com/file/529018501538081/hhvm-jit-...
      [3] https://research.facebook.com/file/700800348487709/HHVM_ICPE...
    • Ich war früher Facebook-Engineer, und das PHP der frühen Facebook-Zeit hatte mit dem PHP, das man für Website-Templates verwendete, kaum etwas gemeinsam. Es gab jede Menge spezialisierte Bibliotheken, die einen deutlich ausgefeilteren Programmierstil ermöglichten
      Man kann sich darunter funktionale Helper, asynchrone Ausführung über Tausende von Cores hinweg und Spanning Trees über Rechenzentren hinweg per SSH vorstellen. Nebenbei: Viele der guten Dinge, die ich benutzt habe, stammten von Evan Priestley; er hat auch Phabricator und mehrere andere leistungsfähige Systeme gebaut
    • Stimmt. Reines Python war nicht schnell genug, also war mehr Arbeit nötig
      „Es läuft auf Instagrams Cinder-Fork, der JIT, Lazy-Loading-Module, vorkompilierte statische Module und mehrere interessante Änderungen gegenüber reinem Python 3.10 enthält“
      Das stand im Tweet
      Persönlich ist es mir egal, welche Sprache Leute verwenden. Jeder weiß: Wenn man Geld hat, stellt man einfach mehr Server dazu. Jedenfalls bis CFO und CTO wegen der Rezession „Kosten senken“ zur nächsten großen Aufgabe erklären
      Es ist erstaunlich, dass 2023 immer noch über die „Production Readiness“ gängiger Programmiersprachen gestritten wird. Wirkt fast wie ein Wettbewerb darum, wer zu den „coolen Kids“ gehört
    • Du meinst die Firma, die tatsächlich zwei PHP-Implementierungen und einen C++-Transpiler bauen musste, um skalieren zu können?
    • Bei der Sprachwahl sieht man oft den Wald vor lauter Bäumen nicht. Wenn man statt Python C++ wählt, um Nanosekunden oder CPU-Zyklen zu sparen, verblasst das gegenüber den Millisekunden, die man an Netzwerkgrenzen verbringt, weil man Cache-Dienste oder Datenbanken liest

  • Die Teile, die tatsächlich viel Performance brauchen, liegen in mehreren C++-basierten Aggregations- und Empfehlungssystemen. Der Webserver ist aber tatsächlich Django

    • Dieses Thema interessiert mich wirklich sehr. Mich würde interessieren, woher man weiß, dass der Webserver Django ist. Ich habe gesucht, aber nichts gefunden
      Warum würden sie Django verwenden? Ich habe es bei kleinen Projekten ausprobiert, aber es ist nicht besonders schnell, und ich hätte gedacht, dass es für so eine große App nicht passt. Ich würde gern die Vor- und Nachteile verstehen
      Warum haben sie es nicht in C++ oder Rust gebaut? Selbst wenn die schweren Teile in einer kompilierten Sprache geschrieben sind, begrenzt Python nicht die Antwortzeiten? Ich bin Amateur, die Frage ist also vielleicht naiv
    • Dass sie sich für Django entschieden haben, ist interessant und erfreulich, aber mich interessiert die Quelle
    • Django ist kein Webserver, sondern ein WSGI/ASGI-Framework. Mich würde interessieren, womit die HTTP-Terminierung tatsächlich erfolgt
    • Mich würde interessieren, wie intensiv in der Codebasis Type Annotations und Typprüfung genutzt werden
    • Korrigiert mich gern, falls ich falschliege, aber Django ist kein Webserver. Es ist ein Framework, das man zusammen mit einem App-Server wie gunicorn und einem Webserver wie nginx verwendet

  • „Es läuft auf Instagrams Cinder-Fork, der JIT, Lazy-Loading-Module, vorkompilierte statische Module und mehrere interessante Änderungen gegenüber reinem Python 3.10 enthält“
    Also ist es nicht einfach nur Python 3.10

    • Ich habe schon einmal Code von Cinder nach CPython portiert. In diesem Fork gibt es einige Optimierungen, die sich leicht in CPython einbringen ließen, und Facebook ist offen dafür, Features zu portieren
      Ich weiß nicht, ob Facebook den Fork dauerhaft weiter pflegen will, aber die CPython-Seite ist offen dafür, solche Features zu mergen, wenn sie sinnvoll sind
    • Man sollte auch daran denken, dass Python 3.10 neun Major-Versionen weiter ist als 3.1
    • Genau genommen ist Python eine Spezifikation, keine Implementierung

  • Dass ein Beitrag über das Threads-Backend auf Twitter gepostet wurde, ist ironisch

    • Wenn man die echte Ironie sucht, dann ist es das: Eine App namens Threads wird mit Python betrieben, das wegen seines globalen Interpreter-Locks Threading erschwert
      Verstanden? Threads, threading…? Schon gut, ich finde selbst hinaus
    • Threads ist wie Instagram eine rein mobile App. Da man Threads im Desktop-Browser praktisch nicht nutzen kann, wurde es wohl deshalb als Twitter-Post geteilt
      Selbst wenn es ein Threads-Post gewesen wäre, hätte man ihn vermutlich nicht bei HN einreichen können
    • Es gibt noch keine Web-App. Man kann wohl direkt auf einen Thread verlinken, aber es wird nur das Verlinkte angezeigt und keine Diskussionsstruktur oder Ähnliches
      Es ist noch nicht fürs Web geöffnet. Angeblich soll das irgendwann kommen
    • Warum wird das runtergevotet? Das ist ein fairer Punkt
    • Gibt es derzeit eine webbasierte Version von Threads, oder nur die App?

  • Dass sich das Backend bis zu einem gewissen Grad überschneidet, ist klar. https://www.threads.net/t/C ist der erste Instagram-Post, ist aber auch auf Threads sichtbar und hat exakt dieselbe Anzahl an Likes wie auf Instagram.
    Auf https://www.threads.net/@kevin steht allerdings, dass es keine Threads gibt.

  • Python ist lediglich der Webserver. Die wirklich performancekritischen Komponenten – Edge-Proxys, Load Balancer, Backend-Services, Datenbanken, Caches und Storage-Services – sind größtenteils in C++ geschrieben.

    • Einen Webserver, der alle oder die meisten Requests verarbeitet, würde ich durchaus als performancekritischen Teil des Systems sehen. Allein ein simples Neuschreiben von Python nach Go bringt in vielen Fällen eine 2- bis 3-fache Performance-Steigerung, und auf FAANG-Niveau kann das bei den Hardwarekosten einen großen Unterschied machen.
    • Genau so war Python gedacht, und genau so wurde es schon immer eingesetzt.

  • Ich habe an Cinder und am Webserver gearbeitet. Wenn es technische Fragen gibt, kann ich sie beantworten. :)

    • Ich frage mich, ob Cinder bei der Optimierung von Echtzeit-Streaming helfen könnte. Wir empfangen UDP-Streams und führen nach allerlei gstreamer- und nvidia-deepstream-Magie Machine-Learning-Inferenz in Echtzeit auf den Streams aus. Soweit ich weiß, hat ein Senior Developer das in Python implementiert.
      Hier war Latenz allerdings ein großes Problem, und wie immer wurde die Optimierung zugunsten des Erreichens des MVP niedriger priorisiert.
      Daher frage ich mich, ob man Cinder zur Optimierung von Echtzeit-Datenstreaming einsetzen kann – oder ob schon die Frage zeigt, dass ich den Use Case nicht verstanden habe.
      Nebenbei haben wir auch Django eingesetzt, und im Nachhinein frage ich mich, ob wir auf FastAPI hätten wechseln sollen. Das ist aber eine separate Frage.
    • Ich frage mich, welches Feature, von dem man hofft, dass es in CPython gemergt wird, die größte Wirkung hätte und zugleich am wahrscheinlichsten ist.
    • Ich frage mich, ob du für einen Stack aus Django, Cython und Numpy den Einsatz von Cinder empfehlen würdest.
    • Kannst du die Webserver-Seite genauer erklären? Implementiert ihr WSGI?
    • Wer profitiert von Cinder? Für welche Art von Workloads ist es geeignet? Das README allein ist etwas dürftig.

  • Ich würde gern mehr über den Rollout erfahren. Es kommen pro Stunde weit über eine Million neue Nutzer hinzu, das ist ziemlich enorm.

    • Ich nehme an, dass sie im Moment massiv überprovisioniert haben, um die ersten Wochen, vielleicht Monate des erwarteten Wachstums abzufangen.
      Trotzdem gibt es sicher viele interessante Details, die man gern hören würde.
    • Über alle Meta-Produkte hinweg gibt es 3,8 Milliarden monatlich aktive Nutzer.
      Ein paar Millionen neue Nutzer sind weniger als 0,1 % des Gesamtwerts. Das liegt problemlos innerhalb erwartbarer Schwankungen.
    • Es läuft einfach auf der gemeinsam genutzten Meta-Infrastruktur, die für diese Größenordnung gebaut wurde.

  • https://github.com/twitter/the-algorithm/pull/447 sollte man nie vergessen.

    • Endlich gibt es einen Unterschied zwischen den beiden.

  • Threads verwendet das Backend/die API von Instagram wieder. Instagram war von Anfang an Python-basiert, daher nutzt auch Threads Python.
    Das bedeutet aber nicht, dass man Python wählen sollte, wenn man so eine App neu baut und es Alternativen gibt, die keinen internen Fork benötigen. Wenn man den ganzen Artikel liest, ist das ziemlich leicht zu verstehen, aber die „nur Überschrift lesen“-UI von Hacker News verzerrt das vermutlich.

    • Ruhig bleiben. Python ist eine völlig gute Sprache.