Engineering

Engineering

Wie Mythex gebaut und betrieben wird – inklusive dessen, was kaputtging, und wie wir es behoben haben.

• Ein fehlgeschlagenes Republish löscht nie ein funktionierendes Backend — Ein fehlgeschlagenes Republish könnte die API einer App löschen oder eine kaputte Version am Laufen lassen. Drei Korrekturen am Rückgängigmachen von Publishes.
• Alarme, die einmal auslösen, nicht einmal pro Server — Ein täglicher Alarm kam an einem Nachmittag fünfmal. Warum Deduplizierung im Arbeitsspeicher mit zwei Servern scheitert und wie geteilter Zustand es behob.
• Auf größere Arbeitsbereiche umstellen, ohne dass jemand warten muss — Nach der Umstellung auf 2 GB blieb ein Viertel unserer Arbeitsbereiche bei 1 GB. Unser erster Fix ließ eine Person sieben Minuten warten. Was wir änderten.
• Datenbanken nach tatsächlicher Nutzung abrechnen — Früher schätzten wir die Datenbankkosten jeder App, und die Schätzung lag daneben. Jetzt wird jede Datenbank stündlich nach gemessener Nutzung berechnet.
• Apps erkennen, die direkt nach dem Publizieren abstürzen — Drei Publishes bestanden den Health-Check, obwohl die API nach Sekunden abstürzte. Die Absturzzählung lief über eine Liste mit nur fünf Einträgen.
• Bildlastige Agenten-Züge im Arbeitsspeicher halten — Ein Agenten-Zug, der Katalogscans immer wieder ansah, lief bei 952 MB aus dem Arbeitsspeicher. Drei getrennte Ursachen hielten Bilder zu lange fest. So haben wir sie behoben.
• Lange Agenten-Züge im Kontextfenster halten — Sub-Agenten wuchsen, bis das Modell sie ablehnte, hörten früh auf oder zählten russische Tokens falsch. Drei Korrekturen, damit lange KI-Arbeit fertig wird.
• Den Chat am Laufen halten, wenn ein Handy schläft — Handys schlafen, wechseln Tabs und verlieren das Netz. Zwei Fehler ließen den Chat hängen oder nur halbe Antworten zeigen. So haben wir sie gefunden und behoben.
• Wie ein einziger schwerer Chat unsere API lahmlegen konnte — Am 28. September liefen beide API-Server gleichzeitig aus dem Speicher. Die eigentliche Lösung: Chat-Verlauf nach Größe statt nur nach Anzahl laden.
• Zweimal Publish drücken veröffentlicht jetzt nur einmal — Drei Veröffentlichungen derselben App kamen 84 ms auseinander an und starteten jeweils ein Deployment. Jetzt entscheidet die Datenbank, wer veröffentlicht.
• SEO-Lektionen aus der Korrektur unserer eigenen Website — Doppeltes FAQ-Markup, das falsche Vorschaubild bei Google, Vorlagenseiten ohne Klicks und ein Pfad, den unser Edge abwies: was wir auf mythex.ai gefunden und behoben haben.
• Statische Websites bleiben jetzt online, während sie neu veröffentlicht werden — Früher wurde eine statische Website vor dem Upload geleert. Jetzt bleibt die alte Version online, bis die neue steht, und Änderungen erscheinen in Sekunden.
• Der Speicherüberlauf, der sich in einer Fortschrittsanzeige versteckte — Unser KI-Agent lief beim Schreiben einer großen Datei aus dem Speicher. Schuld war weder das Modell noch Subagenten, sondern eine Statusanzeige, die 41.000-mal gesendet wurde.
• Die fehlende Swap-Datei, die unsere Server einfrieren ließ — Ein Produktionsserver antwortete nicht mehr, ohne abzustürzen: kein Speicherabbruch, nur Thrashing auf einer Maschine ohne Swap. Was passiert ist und was wir geändert haben.
• Datenbanken aufwecken, ohne tote Verbindungen — Eine veröffentlichte App hielt die erste Anfrage nach dem Aufwachen 10 bis 12 Sekunden auf toten Datenbankverbindungen. Wie wir es auf 2,3 Sekunden gebracht haben.
• Wir haben unsere eigenen Dienste gedrosselt — Das Limit pro Adresse unserer API behandelte eigene Dienste wie eine einzelne Person, und die Produktion bekam 429-Fehler. Wie wir es fanden und behoben.
• Warum wir die Server von Mythex auf ARM umgestellt haben — Nachdem schwere Arbeit in Sandboxes gewandert war, nutzten unsere Server nur ein Drittel ihres Speichers. Kleinere ARM-Instanzen senkten die Kosten um rund 30 Prozent.
• Wie wir Deployments auf null 502-Fehler gebracht haben — Ein Watchdog, der mit unseren Deployments kollidierte, und ein Load Balancer, der zu spät reagierte. Wir behoben beides und brachten Deployments auf null 502-Fehler.