Spații de lucru mai mari, fără ca nimeni să aștepte

Fiecare proiect Mythex primește propriul spațiu de lucru: un mic calculator în cloud în care agentul scrie cod și rulează previzualizarea aplicației tale. Am ridicat memoria noilor spații de lucru de la 1 GB la 2 GB, dar cele vechi au rămas la 1 GB — în ziua în care am verificat, aproximativ un sfert dintre ele. Prima noastră soluție muta un proiect într-un spațiu mai mare la următoarea deschidere. În prima zi în producție, asta a făcut o persoană să aștepte șapte minute. Am pus o limită de timp fermă, apoi am scos mutarea din deschiderea oricărui proiect.

De ce spațiile vechi au rămas mici

Furnizorul nostru de sandbox stabilește dimensiunea unui spațiu de lucru la creare și o păstrează prin fiecare pauză și reluare. Schimbarea șablonului — rețeta din care sunt construite spațiile noi — afectează doar spațiile create după schimbare. Nimic nu redimensionează pe cele existente.

Asta conta. Unul dintre spațiile mici a rămas fără memorie în timpul unui git push, cât timp previzualizarea pornea, și nu a mai răspuns 11 minute. O publicare a eșuat din cauza asta.

Prima încercare: mutarea proiectului la trezire

Spațiile de lucru se pun pe pauză când nu le folosește nimeni și se trezesc când proiectul este deschis. Trezirea părea momentul potrivit pentru mutare, pentru că nimeni nu lucra încă în proiect.

Mutarea funcționa astfel:

1. Verifică dimensiunea. Dacă spațiul de lucru are mai puțin de 2 GB, îl mutăm. Dacă dimensiunea este necunoscută, nu facem nimic.
2. Nu deranja o publicare. O publicare citește fișierele spațiului de lucru, deci dacă una rulează, mutarea se sare.
3. Împachetează proiectul. Arhivează tot ce ține de proiect — inclusiv istoricul lui git, adică fiecare checkpoint al proiectului, și fișierul .env al aplicației, care aparține proprietarului — dar lasă afară dependențele instalate (node_modules), care pot fi reinstalate.
4. Copiază direct. Transmite arhiva din spațiul vechi către un spațiu nou de 2 GB, astfel încât ea să nu trebuiască să încapă niciodată în memoria propriului nostru server.
5. Compară înainte de a comuta. Numără fișierele, citește ultimul checkpoint și numără checkpoint-urile, în ambele spații. Comută doar dacă toate cele trei se potrivesc.
6. Păstrează spațiul vechi la orice eșec. Orice eroare sau nepotrivire aruncă spațiul nou și deschide proiectul în cel vechi, ca înainte.

Un detaliu din comparație a contat mai mult decât pare. Verificarea rulează ca cont de administrator, iar git refuză să citească un depozit care aparține altui utilizator. Nu a afișat nimic de ambele părți — iar „nimic” s-a potrivit cu „nimic”, deci verificarea a trecut fără să compare de fapt vreun istoric. Am spus git să aibă încredere în director și am adăugat un test ca asta să nu mai poată strecura din nou.

Ce a mers prost în prima zi

În prima zi în producție, împachetarea unui proiect a lovit o limită de cinci minute a comenzii — în interiorul trezirii. Proprietarul a așteptat șapte minute până s-a deschis spațiul lui de lucru. Și, pentru că mutarea eșuase, proiectul rămânea mic, deci deschiderea următoare ar fi încercat din nou și l-ar fi făcut să aștepte din nou.

O migrare care face pe cineva să aștepte la deschiderea propriului proiect este un schimb prost. Ideea întregii abordări de a o face la trezire era că nimeni nu avea să observe.

A doua încercare: un buget ferm

În aceeași zi am schimbat patru lucruri:

• Un minut pentru întreaga mutare. Fiecare pas — verificarea dimensiunii, împachetarea, crearea spațiului nou, copierea, dezarhivarea, compararea — împarte un singur buget de 60 de secunde. Când se termină, proiectul se deschide în spațiul vechi.
• Oprește lucrul, nu doar așteptarea. Renunțarea de partea noastră nu ajunge dacă arhivarea rulează încă în spațiul pe care proprietarul urmează să-l folosească. Fiecare comandă de arhivare este acum oprită în interiorul spațiului, cu puțin înainte de sfârșitul bugetului. Dacă noul spațiu sosește după ce am renunțat, este aruncat.
• Nu-l face pe proprietar să aștepte curățenia. Ștergerea arhivei temporare se face acum în fundal.
• Nu încerca din nou la fiecare deschidere. Un proiect care nu a putut fi mutat este lăsat în pace timp de 24 de ore, deci un eșec costă cel mult o întârziere pe zi, nu una la fiecare deschidere.

A treia încercare: scoate-o din trezire

Asta a adus cel mai rău caz la un minut. Dar un minut tot înseamnă un minut, iar noi ne-am dat seama că mutarea nu trebuia să fie pe drumul nimănui.

Niciun spațiu de lucru nu mai este creat la 1 GB. Deci asta nu este un proces continuu; este o sarcină unică, cu o listă fixă de spații de lucru. Făcută în interiorul trezirii, o persoană reală plătea pentru fiecare mutare lentă, iar singurul mod în care aflam că un spațiu nu se mută era că cineva tocmai aștepta după el.

Așa că am scos mutarea din trezire complet. Deschiderea unui proiect face ce făcea înainte. Spațiile mici rămase sunt tratate acum ca un lot supravegheat: nu așteaptă nimeni după ele, iar un spațiu care nu se poate muta apare în raportul lotului, unde îl putem analiza, în loc să apară în fața persoanei care îl deține.

Ce am învățat

• Redimensionarea nu este întotdeauna posibilă. Când o platformă fixează o dimensiune la creare, creșterea valorii implicite ajută doar lucrurile noi. Planifică pentru cele vechi.
• „Nu-l folosește nimeni încă” tot înseamnă că cineva așteaptă. Lucrul făcut pe drumul spre un produs este lucru pe care o persoană îl urmărește.
• Pune un buget pe orice este în calea unui utilizator și oprește lucrul când bugetul se termină. Expirarea pe partea noastră, în timp ce o comandă continuă să ruleze în altă parte, doar mută problema.
• O migrare unică aparține unui job unic. Ascunsă în acțiunile de zi cu zi, devine mai ieftină de scris și mai scumpă de rulat.
• Testează-ți verificările de siguranță. O comparație care nu compară nimic arată exact ca una care a trecut.

Dacă construiești pe Mythex, nu ai nimic de făcut: scopul este pur și simplu mai puține spații de lucru care rămân fără memorie, iar deschiderea unui proiect la fel de rapidă ca înainte. Cum se pun pe pauză și se trezesc spațiile de lucru este descris în documentație, la spațiu de lucru privat. Pentru o altă poveste despre memorie epuizată, vezi crash-ul din memorie ascuns într-o etichetă de progres.