Wikifunctions:Status-Updates/2024-08-23
| ◀ |  Wikifunctions Status-Updates  |
▶ |
|
WasmEdge, jetzt 300 ms weniger langsam
In diesem Quartal hat sich das Team Abstrakte Wikipedia dazu verpflichtet, die Systemleistung zu verbessern. Wir haben eine Engpassanalyse der Funktionsaufrufe durchgeführt und verfolgt, wie viel Zeit das System mit HTTP-Anfragen, Berechnungen und Ressourcenverwaltung verbracht hat. Wir haben festgestellt, dass der – mit Abstand! – langsamste Vorgang das Starten der WasmEdge-CLI war.
Wir haben bereits über WasmEdge gesprochen: Kurz gesagt handelt es sich um eine Systemschnittstelle für WebAssembly (WASM). Sie ermöglicht die Interaktion von WASM-Code mit dem Betriebssystem. Wir verwenden sie hauptsächlich, damit unsere Code-Ausführer Standard-Datenströme lesen/schreiben können und dabei garantiert nichts anderes berühren – keine Dateien, keinen Netzwerkzugriff und keine anderen Prozesse – was ein wichtiger Teil unserer Arbeit ist, um die Integrität und Sicherheit der Dienste zu gewährleisten. Leider stellt sich heraus, dass WasmEdge in unserer Produktionsumgebung etwa 300 ms zum Hochfahren benötigt, bevor es bereit ist, Daten zu verarbeiten.
Die Lösung, die wir für dieses Problem entwickelt haben, besteht darin, mehrere WasmEdge-Prozesse ständig laufen zu lassen. Auf diese Weise muss der Auswerter bei einer Anfrage nicht warten, bis ein neuer Prozess bereit ist: Stattdessen kann er einfach einen bereiten Prozess aus dem Pool auswählen und deine Anfrage sofort ausführen.
Wir haben diese Änderungen am Mittwoch implementiert und wie viele bereits bemerkt haben, ist Wikifunctions deutlich schneller geworden. Herzlichen Glückwunsch an das Team für die Implementierung!
Letzte Änderungen an der Software
Wie oben erwähnt, war die größte Neuerung, die wir diese Woche eingeführt haben, eine umfassende Neufassung der Funktionsweise des Back-End-"Auswerter"-Dienstes, von der wir hoffen, dass sie die wahrgenommene Leistung deutlich verbessern wird. Dies ist eine der großen Aufgaben, die wir uns für dieses Quartal vorgenommen haben. Anstatt WASM auf Anfrage zu laden, laden wir es jetzt vorab in einen Pool bereiter Threads (T371837). Nach einigen ersten Tests scheinen die Aufrufe bei Einzelanfragen (je nach Bedarf) etwa 3–12-mal schneller und bei gesättigten Anfragen 30 % schneller zu sein, aber wir sind gespannt, wie gut es in der Praxis für dich funktioniert!
Wir haben auch einige Front-End-Verbesserungen vorgenommen. Beim Bearbeiten von Bezeichnungen von Funktionen zeigen wir jetzt die Längenbeschränkung (T370995) für neue Bezeichnungen an und setzen sie im Front-End durch. Wenn du zuvor eine Bezeichnung erstellt hast, die länger als die neuen Beschränkungen ist, empfehlen wir dir, sie innerhalb der neuen Beschränkung zu kürzen. Wir geben jedem etwas Zeit und Hilfe, um dies zu tun, und werden versuchen, die Beschränkung durchzusetzen, sobald alle Bezeichnungen fertig sind. Weitere Details werden in zukünftigen Updates bekannt gegeben. Wir haben auch einen Fehler behoben, der dazu führte, dass auf Funktionsseiten die Kontrollkästchen in den Tabellen für Implementierungen und Testfälle falsch ausgerichtet waren.
Wir haben einen Fehler behoben, der dazu führte, dass wir unter bestimmten Umständen Metadatenobjekte mit einem Schlüssel und ohne Informationen erstellten (T369625). Wir haben unseren Code neu geschrieben, sodass wir die Logik zum Ändern des angezeigten Seitentitels, wenn du die Bezeichnung zwischen dem Funktionseditor und dem Editor im "Info-Dialog" änderst, gemeinsam nutzen, um Konsistenz zu gewährleisten und das Risiko von Fehlern zu vermeiden (T371350).
Wir haben an einigen API- und allgemeinen Codeverbesserungen gearbeitet, um Code konsistenter und zuverlässiger zu teilen. Dadurch konnten wir ein Feature-Flag für die 'Repo'-Natur des WikiLambda-Codes hinzufügen. Dies bedeutet, dass wir in Zukunft die Erweiterung im 'Client'-Modus auf anderen Wikis installieren können, als Teil der Arbeit, dir das Einbetten von Aufrufen von Wikifunctions in Artikeln mithilfe von Wikitext zu ermöglichen.
Im Rahmen unserer "Reparatur"-Arbeit zur Beseitigung technischer Rückstände vor zwei Wochen konnten wir einige weitere Verbesserungen erzielen. Die größte davon war eine umfassende Neufassung unseres Front-End-Styling-Codes zur Verwendung einheitlicher Namenskonventionen (dokumentiert auf MediaWiki.org), wodurch wir eine Reihe von derzeit nicht verwendeten Codestellen und eine fest codierte i18n-Bezeichnung (T369596) fanden. Wir haben einige Tests der Browserverlaufsbearbeitung der Wikifunctions UX-Anwendung hinzugefügt, da dies ein kniffliger und verwirrender Bereich ist. Wir haben auch einige i18n-Bezeichnungen optimiert, um Übersetzern zu zeigen, wo die {{PLURAL:$1|$1 …|$1 …}}-Syntax platziert werden muss.
Unsere sprachliche Vielfalt ist unsere Stärke
Nachdem ich bei der Wikimania so viele mehrsprachige Benutzer aus unserer Community getroffen hatte, wurde ich dazu inspiriert, mehr über dieses Thema nachzudenken.
Obwohl ich mehrere Jahre damit verbracht habe, das Programmieren zu lernen und aktiv zu programmieren, hatte ich noch nicht ganz begriffen, welche subtile, aber entscheidende Rolle Sprachkenntnisse dabei spielen, ein Programmierer zu sein, der qualitativ hochwertigen Code schreibt. Wenn du gut Englisch sprichst, werden die vorgefertigten Funktionen beliebter Programmiersprachen für dich mehr Sinn haben, du kannst eigene Funktionen natürlich besser benennen, du kommentierst besser, und ich könnte diese Auflistung fortführen. Was unser Team jeden Tag dazu antreibt, Wikifunctions zu verbessern, ist die revolutionäre Idee, Benutzern zu ermöglichen, Code in ihrer eigenen Sprache zu schreiben. Dieser Ansatz bringt uns über das Konzept einer einzigen dominanten Sprache hinaus und schafft gleiche Bedingungen, die es Benutzern ermöglichen, auf ihre eigene Weise zu schreiben. Exzellente Funktionen haben sehr wenig mit der natürlichen Sprache ihrer Bezeichnungen zu tun, aber dennoch sehr viel mit dem Aufbau unserer vielfältigen Benutzergemeinschaft. Wir ermutigen dich, in deiner Muttersprache zu schreiben.
Wo wir von Bezeichnungen sprechen: Wenn du neu bei Wikifunctions bist und dir noch nicht sicher bist, wie man Funktionen schreibt, kannst du zu unserer lebhaften Community beitragen, indem du Funktionsbezeichnungen und -beschreibungen in deine Sprache übersetzt. Du kannst auch eine Funktion vorschlagen, die in deiner Sprache erstellt werden soll.
Funktion der Woche: Blutverträglichkeit
In den letzten Wochen habe ich radikal unterschiedliche Funktionen ausgewählt, um die Vielfalt unserer Funktionsbibliothek bereits in ihrem frühen Stadium zu demonstrieren. Um dies fortzusetzen, habe ich diese Woche ein Werkzeug für die Blutverträglichkeit ausgewählt. Diese Funktion prüft, ob zwei Blutgruppen kompatibel sind, und hilft dabei festzustellen, ob eine Blutspende oder ein Erhalt der Blutgruppe möglich ist.
Die Funktion nimmt zwei Zeichenketten-Eingaben für die Blutgruppen, die wir vergleichen möchten, und gibt ihre Kompatibilität in Form eines booleschen Wertes aus. Wenn du beispielsweise ‘A’ und ‘B’ als die Typen eingibst, deren Kompatibilität du kennen möchtest, bedeutet das Ergebnis ‘wahr’, dass sie kompatibel sind, und ‘falsch’, dass dies nicht der Fall ist. Vielleicht kann die Funktion in Zukunft so geändert werden, dass ein spezieller Typ zur Darstellung der Blutgruppe verwendet wird, aber im Moment funktioniert dies gut genug.
Die Funktion hat derzeit eine Implementierung in Python, die zwei Blutgruppen als Eingabe akzeptiert, sie in Großbuchstaben umwandelt und prüft, ob es sich um gültige Blutgruppen handelt. Anschließend prüft sie, ob das Blutgruppenpaar (entweder in der angegebenen Reihenfolge oder umgekehrt) in der vordefinierten Plasma-Tabelle vorhanden ist, die kompatible Plasmaspenden-Paare auflistet. Wenn das Paar in der Tabelle gefunden wird, gibt die Funktion wahr zurück, was für Kompatibilität steht; andernfalls gibt sie falsch zurück. Wenn eine der Blutgruppen ungültig ist, gibt sie leer zurück.
Derzeit gibt es zwei Tests, die demonstrieren, was von der Funktion zu erwarten ist. Einer für eine kompatible Gruppe und ein anderer für Nicht-Kompatibilität. Wir empfehlen dir, weitere Implementierungen und die Behandlung von Randfällen hinzuzufügen, um diese Funktion zu verbessern.