Suuremate töötubade juurde liikumine nii, et keegi ei pea ootama

Igal Mythexi projektil on oma töötuba: väike pilvearvuti, kus agent kirjutab koodi ja sinu rakenduse eelvaade töötab. Me tõstsime uute töötubade mälu 1 GB-lt 2 GB-le, kuid vanemad jäid 1 GB peale. Kontrollimise päeval oli neid umbes veerand. Meie esimene parandus viis projekti suuremasse töötuppa järgmisel avamisel. Selle esimesel päeval tootmises pani see ühe inimese seitsmeks minutiks ootama. Me panime sellele kindla ajapiirangu ja seejärel eemaldasime selle liigutamise projekti avamisest üldse.

Miks vanad töötoad jäid väikeseks

Meie liivakasti pakkuja määrab töötoa suuruse selle loomisel ja hoiab selle alles kõigi peatamiste ja taaskäivituste ajal. Töötoa malli muutmine, see retsept, millest uued töötoad luuakse, mõjutab ainult pärast muutmist loodud töötubasid. Olemasolevaid ei muuda miski ümber.

See oli oluline. Üks väike töötuba sai git push ajal mälu otsa, samal ajal kui selle eelvaade käivitus, ja jäi 11 minutiks vastamata. Avaldamine ebaõnnestus selle tõttu.

Esimene katse: liiguta projekt äratamisel

Töötoad peatuvad, kui keegi neid ei kasuta, ja ärkavad, kui projekt avatakse. Äratamine tundus õige hetk projekti liigutamiseks, sest keegi ei tööta selles veel.

Liigutamine toimis nii:

1. Kontrolli suurust. Kui töötuba on väiksem kui 2 GB, liiguta see. Kui suurus on teadmata, ära tee midagi.
2. Ära sega avaldamist. Avaldamine loeb töötoa faile, nii et kui üks jookseb, jäta liigutamine vahele.
3. Paki projekt. Arhiveeri kogu projekt, sealhulgas selle git-ajalugu, mis on kõik projekti kontrollpunktid, ja rakenduse enda .env-fail, mis kuulub omanikule. Jäta välja paigaldatud sõltuvused (node_modules), mida saab uuesti paigaldada.
4. Kopeeri otse üle. Voogesta arhiiv vanast töötoast värskesse 2 GB töötuppa, nii et see ei pea kunagi mahtuma meie enda serveri mällu.
5. Võrdle enne ümberlülitamist. Loenda faile, loe viimane kontrollpunkt ja loenda kontrollpunkte mõlemas töötoas. Lülita ümber ainult siis, kui kõik kolm klapivad.
6. Hoia vana alles igal ebaõnnestumisel. Iga viga või mittevastavus viskab uue töötoa minema ja avab projekti vanas töötoas, nagu varem.

Üks detail võrdluses oli olulisem, kui see paistab. Kontroll jookseb administraatori kontol ja git keeldub lugemast repositooriumi, mis kuulub teisele kasutajale. See ei trükkinud mõlemal pool midagi, ja „mitte midagi” sobis „mitte millegagi”, nii et kontroll läbis, ilma et ta oleks ajalugu üldse võrrelnud. Me ütlesime gitile, et see kataloog on usaldusväärne, ja lisasime testi, et see ei saaks tagasi libiseda.

Mis läks valesti esimesel päeval

Selle esimesel päeval tootmises jõudis ühe projekti pakkimine viieminutilise käsu ajalõpuni äratamise sees. Omanik ootas oma töötoa avanemist seitse minutit. Ja kuna liigutamine ebaõnnestus, oli projekt endiselt väike, nii et järgmine avamine oleks proovinud uuesti ja pannud nad uuesti ootama.

Migratsioon, mis paneb inimese ootama oma projekti avamisel, on halb kompromiss. Kogu mõte oli teha see äratamisel, et keegi ei märkaks.

Teine katse: kindel eelarve

Sama päeva jooksul muutsime neli asja:

• Üks minut kogu liigutamise jaoks. Iga samm (suuruse kontroll, pakkimine, uue töötoa loomine, kopeerimine, lahtipakkimine, võrdlus) jagab ühte 60-sekundilist eelarvet. Kui see saab otsa, avatakse projekt vanas töötoas.
• Peata töö, mitte ainult ootamine. Meie poolelt loobumine ei piisa, kui arhiveerimine jookseb endiselt töötoas, mille omanik on kohe kasutamas. Iga arhiveerimiskäsk tapetakse nüüd töötoas endas veidi enne eelarve lõppu. Kui uus töötuba saabub pärast seda, kui oleme loobunud, viskame selle minema.
• Ära pane omanikku ootama koristamist. Ajutise arhiivi kustutamine toimub nüüd taustal.
• Ära proovi igal avamisel uuesti. Projekt, mida ei saanud liigutada, jäetakse 24 tunniks rahule, nii et ebaõnnestumine maksab kõige rohkem ühe viivituse päevas, mitte ühe iga avamise kohta.

Kolmas katse: too see äratamisest välja

See tegi halvima juhtumi üheminutiliseks. Aga minut on ikka minut ja me mõistsime, et liigutamine ei pidanud üldse kellegi teekonnal olema.

1 GB töötubasid enam ei looda. See ei ole seega pidev protsess, vaid ühekordne töö kindla töötubade nimekirjaga. Selle tegemine äratamise sees tähendas, et päris inimene maksis iga aeglase liigutamise eest, ja ainus viis teada saada, et töötuba ei liigu, oli see, et keegi oli just selle eest oodanud.

Seetõttu eemaldasime liigutamise äratamisest täielikult. Projekti avamine teeb sama, mis enne. Ülejäänud väikesed töötoad käsitletakse nüüd järelevalve all oleva partiitööna: keegi ei oota seda, ja töötuba, mis ei liigu, ilmub partii aruandes, kus me saame seda vaadata, mitte selle omaniku ees.

Mida sellest õppisime

• Suuruse muutmine ei ole alati võimalik. Kui platvorm määrab suuruse loomisel, aitab vaikeväärtuse tõstmine ainult uusi asju. Planeeri vanade jaoks.
• „Keegi ei kasuta seda veel” tähendab ikka, et keegi ootab. Töö, mis tehakse toote sisenemisel, on töö, mida inimene jälgib.
• Pane eelarve kõigele, mis on kasutaja teekonnal, ja peata töö, kui eelarve saab otsa. Ajalõpp meie poolel, kui käsk jookseb edasi mujal, nihutab probleemi ainult ära.
• Üks kord tehtav migratsioon kuulub ühekordsesse tööse. Selle peitmine igapäevaste tegevuste sisse teeb selle kirjutamise odavamaks ja jooksutamise kallimaks.
• Testi oma ohutuskontrolle. Võrdlus, mis ei võrdle midagi, näeb täpselt välja nagu see, mis läbis.

Kui ehitad Mythexil, pole midagi teha: eesmärk on lihtsalt vähem töötubasid, mis jooksevad mälu otsa, ja projekti avamine sama kiire kui varem. Kuidas töötoad peatuvad ja ärkavad, on dokumenteeritud privaatse töötoa all. Teise mälu otsa jooksmise loo kohta vaata mälulekke lugu edenemissildis.