Inxhinieri

Inxhinieri

Si ndërtohet dhe funksionon Mythex, përfshirë çfarë u prish dhe si e rregulluam.

• Një ripublikim i dështuar nuk fshin kurrë një backend që funksionon — Një ripublikim i dështuar mund të fshinte API-n live të një aplikacioni. Tre rregullime si Mythex e zhbën një publikim që dështon.
• Alarme që ndizen një herë, jo një herë për çdo server — Një alarm ditor arriti tek ne pesë herë brenda një pasdite. Pse deduplikimi në memorje prishet me dy serverë dhe një deploy, dhe si e rregulloi gjendja e përbashkët.
• Kalimi në hapësira pune më të mëdha pa e bërë askënd të presë — Një e katërta e hapësirave mbeti në 1 GB pas kalimit në 2 GB. Rregullimi i parë i bëri një person të presë shtatë minuta. Çfarë ndryshuam.
• Faturimi i bazave të të dhënave sipas asaj që përdorin vërtet — Dikur vlerësonim koston e bazës së çdo aplikacioni, dhe vlerësimi ishte i gabuar në të dy drejtimet. Tani çdo bazë faturohet sipas përdorimit të matur.
• Kapja e aplikacioneve që rrëzohen menjëherë pas publikimit — Tre publikime kaluan kontrollin tonë të shëndetit ndërsa API-ja e tyre rrëzohej sekonda pas çdo nisjeje. Shkaku: rrëzimet numëroheshin në një listë të kufizuar në pesë hyrje.
• Mbajtja e turneve të agjentit me shumë imazhe brenda memories — Një turn agjenti që shikonte vazhdimisht skanime katalogu mbaroi memorien në 952 MB. Tre shkaqe të ndara, secili duke mbajtur imazhet më gjatë se duhet, dhe si i rregulluam.
• Mbajtja e turneve të gjata të agjentit brenda dritares së kontekstit — Nën-agjentët rriteshin derisa modeli i refuzonte, ndalonin herët për hapësirë, dhe numëronin gabim tokenët në rusisht. Tri rregullime që e lanë punën e gjatë të përfundojë.
• Mbajtja e chat-it gjallë kur telefoni fle — Telefonat flenë, ndërrojnë skedat dhe humbin rrjetin gjatë ndërtimit. Dy gabime e bënin chatin të ngecë ose të shfaqte gjysmë përgjigjeje. Si i gjetëm dhe i rregulluam.
• Si një chat i rëndë mund ta rrëzonte API-n tonë — Më 28 shtator, të dy serverat API mbaruan memorien njëkohësisht. Rregullimi i parë ishte më shumë memorie; i vërtetë ishte ngarkimi i historikut sipas madhësisë.
• Shtypja e Publish dy herë tani publikon vetëm një herë — Tre kërkesa publikimi për një aplikacion arritën 84 ms larg njëra-tjetrës. Tani baza e të dhënave vendos kush publikon, dhe të tjerët marrin të vërtetën.
• Mësime SEO nga rregullimi i faqes sonë — FAQ i dyfishtë, miniatura e gabuar në Google, faqe shabllonesh pa klikime dhe një rrugë e bllokuar nga edge-i: çfarë gjetëm në mythex.ai dhe çfarë rregulluam.
• Sajtet statike mbeten online gjatë ripublikimit — Ripublikimi i sajtit statik nuk e zbraz më para ngarkimit. Sajti i vjetër shërben derisa i riu të vendoset, dhe ndryshimet shfaqen brenda sekondash.
• Crash-i nga mungesa e memories që fshihej në një etiketë progresi — Agjenti ynë AI mbaroi memorien duke shkruar një skedar të madh. Shkaku nuk ishte modeli apo nën-agjentët paralelë — ishte një etiketë statusi e ridërguar 41,000 herë.
• Skedari i mungueshëm i swap-it që ngriu serverët tanë — Një server prodhimi pushoi së përgjigjuri pa u rrëzuar — pa kill për mungesë memorie, vetëm thrashing i page cache-it në një makinë pa swap. Çfarë ndodhi dhe çfarë ndryshuam.
• Zgjimi i bazave të të dhënave pa lidhje të vdekura — Një aplikacion i publikuar që zgjohej nga gjumi e mbante kërkesën e parë 10–12 sekonda mbi lidhje të vdekura. Si e zbritëm në 2.3 sekonda.
• Po e kufizonim veten tonë me rate limit — Kufiri për adresë i API-t tonë e trajtonte shërbimet tona si një përdorues të zënë, dhe në prodhim ato filluan të merrnin 429. Si e gjetëm dhe si e rregulluam.
• Pse e zhvendosëm serverët e Mythex te ARM — Pasi punët e rënda u zhvendosën në sandbox-e për çdo projekt, serverët tanë përdornin një të tretën e memories. Instancat më të vogla ARM zvogëluan kostot me rreth 30%. Si.
• Si arritëm deploy-et në zero gabime 502 — Një watchdog që garonte me deploy-et dhe një load balancer që e vuri re shumë vonë: si i gjetëm të dyja, i rregulluam dhe matëm deploy-et nga 10 gabime 502 në zero.