Enginyeria

Enginyeria

Com es construeix i funciona Mythex, incloent-hi què va fallar i com ho vam arreglar.

• Una republicació fallida mai no esborra un backend que funciona — Una republicació fallida podia esborrar l'API en directe d'una app o deixar en marxa una versió trencada. Tres correccions a com Mythex desfà una publicació errònia.
• Alertes que s'envien una vegada, no una vegada per servidor — Una alerta diària ens va arribar cinc vegades en una tarda. Per què la memòria local falla amb dos servidors i com ho va resoldre un estat compartit.
• Passar a espais de treball més grans sense fer esperar ningú — Un quart dels espais de treball es van quedar a 1 GB. La primera correcció va fer esperar una persona set minuts. Què vam canviar i per què.
• Facturar les bases de dades pel que realment fan servir — Abans estimàvem el cost de la base de dades de cada app, i l'estimació fallava en les dues direccions. Ara cada base de dades es factura a partir de l'ús mesurat, hora a hora.
• Detectar les apps que es bloquegen just després de publicar — Tres publicacions van passar la comprovació de salut mentre la seva API es bloquejava a cada arrencada. Comptar bloquejos en una llista limitada n'era la causa.
• Mantenir els torns de l'agent amb moltes imatges dins de la memòria — Un torn de l'agent amb escanejos de catàleg es va quedar sense memòria a 952 MB. Tres causes, cadascuna retenint imatges massa temps, i com les hem arreglat.
• Mantenir els torns llargs de l'agent dins de la finestra de context — Els subagents creixien fins que el model els rebutjava, s'aturaven per guardar espai o comptaven malament els tokens en rus. Tres solucions per al treball llarg amb IA.
• Mantenir el xat viu quan el telèfon s'adorm — Els telèfons s'adormen i canvien de xarxa durant una construcció. Dos errors deixaven el xat penjat o amb mitja resposta. Com els hem trobat i arreglat.
• Com un xat pesat podia tombar la nostra API — El 28 de setembre, els dos servidors de l'API es van quedar sense memòria alhora. El primer arranjament va ser més memòria; la real, carregar l'historial per mida.
• Prémer Publica dues vegades ara publica només una — Tres peticions de publicació d'una mateixa app arribaven amb 84 ms de diferència i executaven tres desplegaments. Ara la base de dades decideix qui publica.
• Lliçons de SEO després de corregir el nostre propi lloc — FAQ duplicades, una miniatura equivocada a Google, pàgines que ningú clicava i una ruta que el nostre edge rebutjava. Què vam trobar a mythex.ai i com ho hem arreglat.
• Els llocs estàtics ara segueixen en línia mentre es tornen a publicar — Tornar a publicar un lloc estàtic el buidava abans de pujar la nova versió. Ara el lloc antic segueix servint fins que la nova és al seu lloc, i els canvis es veuen en segons.
• La fuita de memòria que s'amagava en una etiqueta de progrés — El nostre agent d'IA es va quedar sense memòria escrivint un fitxer gran. La causa no eren el model ni els subagents: era una etiqueta d'estat reenviada 41.000 vegades.
• El fitxer d'intercanvi que faltava i que va bloquejar els nostres servidors — Un servidor de producció deixava de respondre sense caure: cap assassinat per memòria, només thrashing en una màquina sense swap. Què va passar i què hem canviat.
• Despertar bases de dades sense connexions mortes — Una app publicada que es despertava de la son trigava 10 a 12 segons en la primera petició, per connexions a la base de dades que havien mort. Ara triga 2,3 segons.
• Limitàvem els nostres propis serveis — El límit de peticions per adreça de la nostra API tractava els nostres serveis com una sola persona ocupada, i en producció rebien 429. Com ho hem trobat i arreglat.
• Per què hem mogut els servidors de Mythex a ARM — Quan la feina pesada va passar als sandboxes de cada projecte, els nostres servidors usaven un terç de la memòria. Les instàncies ARM més petites van reduir el cost un 30 %.
• Com hem aconseguit desplegaments amb zero errors 502 — Un watchdog que competia amb els desplegaments i un equilibrador que ho va notar tard: com els vam trobar, arreglar i passar de 10 errors 502 a zero.