મોટા વર્કસ્પેસ પર જવું, કોઈને રાહ જોવડાવ્યા વિના

દરેક Mythex પ્રોજેક્ટને પોતાનું વર્કસ્પેસ મળે છે: એક નાનું ક્લાઉડ કમ્પ્યુટર, જ્યાં એજન્ટ કોડ લખે છે અને તમારી એપનું પ્રિવ્યૂ ચાલે છે. અમે નવા વર્કસ્પેસની મેમરી 1 GB થી વધારીને 2 GB કરી હતી, પણ જૂના વર્કસ્પેસ 1 GB પર જ રહ્યા. જે દિવસે અમે તપાસ્યું, ત્યારે લગભગ એક ચોથા ભાગના આવા હતા. અમારો પહેલો સુધારો હતો કે પ્રોજેક્ટ આગલી વખત ખોલવામાં આવે ત્યારે તેને મોટા વર્કસ્પેસમાં ખસેડવો. પ્રોડક્શનમાં પહેલા જ દિવસે તેના કારણે એક વ્યક્તિને સાત મિનિટ રાહ જોવી પડી. પછી અમે તેના પર કડક સમય મર્યાદા મૂકી, અને આખરે પ્રોજેક્ટ ખોલવાની ક્રિયામાંથી જ આ ખસેડવાનું કામ કાઢી નાખ્યું.

જૂના વર્કસ્પેસ નાના કેમ રહ્યા

અમારો સેન્ડબોક્સ પ્રોવાઇડર વર્કસ્પેસનું કદ તે બનાવાય ત્યારે નક્કી કરે છે, અને દરેક પોઝ અને રિઝ્યુમમાં તે કદ જાળવી રાખે છે. ટેમ્પ્લેટ બદલવાથી, એટલે કે એ રેસિપી જેના આધારે નવા વર્કસ્પેસ બને છે, ફક્ત ફેરફાર પછી બનેલા વર્કસ્પેસ પર અસર થાય છે. જે વર્કસ્પેસ પહેલેથી છે તેનું કદ કંઈ બદલતું નથી.

આ વાત મહત્ત્વની હતી. એક નાના વર્કસ્પેસમાં git push ચાલતી વખતે મેમરી ખતમ થઈ ગઈ, જ્યારે તેનું પ્રિવ્યૂ શરૂ થઈ રહ્યું હતું. તે 11 મિનિટ સુધી પ્રતિસાદ આપતું બંધ રહ્યું. તેના કારણે એક પબ્લિશ નિષ્ફળ ગયું.

પહેલો પ્રયાસ: વર્કસ્પેસ જાગે ત્યારે પ્રોજેક્ટ ખસેડો

જ્યારે કોઈ વપરાશ ન કરે ત્યારે વર્કસ્પેસ પોઝ થઈ જાય છે, અને પ્રોજેક્ટ ખોલવામાં આવે ત્યારે જાગે છે. જાગવાની ક્ષણ પ્રોજેક્ટ ખસેડવા માટે યોગ્ય લાગી, કારણ કે ત્યારે હજી કોઈ તેમાં કામ કરી રહ્યું નથી.

ખસેડવાનું કામ આ રીતે થતું હતું:

1. કદ તપાસો. જો વર્કસ્પેસ 2 GB કરતાં નાનું હોય, તો તેને ખસેડો. જો તેનું કદ ખબર ન હોય, તો કંઈ ન કરો.
2. પબ્લિશને ખલેલ ન પહોંચાડો. પબ્લિશ વર્કસ્પેસની ફાઇલો વાંચે છે, તેથી જો કોઈ પબ્લિશ ચાલુ હોય, તો ખસેડવાનું છોડી દો.
3. પ્રોજેક્ટ પેક કરો. પ્રોજેક્ટની બધી ફાઇલો આર્કાઇવ કરો, જેમાં તેનો git ઇતિહાસ, એટલે કે પ્રોજેક્ટના બધા ચેકપોઇન્ટ, અને એપની પોતાની .env ફાઇલ પણ આવે, જે માલિકની છે. પણ ઇન્સ્ટૉલ થયેલી ડિપેન્ડન્સી (node_modules) છોડી દો, કારણ કે તે ફરીથી ઇન્સ્ટૉલ થઈ શકે છે.
4. સીધું ટ્રાન્સફર કરો. જૂના વર્કસ્પેસમાંથી આર્કાઇવ સીધું નવા 2 GB વર્કસ્પેસમાં સ્ટ્રીમ કરો, જેથી તે અમારા પોતાના સર્વરની મેમરીમાં ક્યારેય ન સમાય.
5. સ્વિચ કરતા પહેલાં સરખાવો. બંને વર્કસ્પેસમાં ફાઇલોની સંખ્યા ગણો, છેલ્લો ચેકપોઇન્ટ વાંચો, અને ચેકપોઇન્ટની સંખ્યા ગણો. ત્રણેય મેળ ખાય તો જ સ્વિચ કરો.
6. કોઈ પણ નિષ્ફળતામાં જૂનું રાખો. કોઈ પણ ભૂલ કે મેળ ન ખાય તો નવું વર્કસ્પેસ કાઢી નાખવામાં આવે છે, અને પ્રોજેક્ટ પહેલાંની જેમ જૂના વર્કસ્પેસમાં ખુલે છે.

સરખામણીની એક વિગત અપેક્ષા કરતાં વધારે મહત્ત્વની હતી. આ તપાસ એડમિનિસ્ટ્રેટર ખાતા તરીકે ચાલે છે, અને git એવા રિપોઝિટરીને વાંચવાની ના પાડે છે જેનો માલિક બીજો યુઝર હોય. બંને બાજુ તેણે કંઈ છાપ્યું નહીં, અને "કંઈ નહીં" એ "કંઈ નહીં" સાથે મેળ ખાઈ ગયું, એટલે તપાસ કોઈ પણ ઇતિહાસની સરખામણી કર્યા વિના પાસ થઈ ગઈ. અમે git ને ડિરેક્ટરી પર ભરોસો કરવાનું કહ્યું, અને એક ટેસ્ટ ઉમેર્યો, જેથી આ ફરી ન થાય.

પહેલા દિવસે શું ખોટું થયું

પ્રોડક્શનમાં પહેલા દિવસે, એક પ્રોજેક્ટ પેક કરતી વખતે જાગવાની અંદર પાંચ મિનિટની કમાંડ ટાઇમઆઉટ લાગી. માલિકને તેમનું વર્કસ્પેસ ખુલવાની રાહ જોવી પડી: સાત મિનિટ. અને ખસેડવાનું નિષ્ફળ ગયું હોવાથી પ્રોજેક્ટ હજી નાનો હતો, એટલે આગલી વખત ખોલતી વખતે ફરી પ્રયાસ થાત અને ફરી રાહ જોવી પડત.

જે વ્યક્તિ પોતાનો પ્રોજેક્ટ ખોલતી વખતે રાહ જુએ એવું સ્થળાંતર ખરાબ સોદો છે. જાગવા પર કરવાનો આખો મુદ્દો એ હતો કે કોઈને ખબર પણ ન પડે.

બીજો પ્રયાસ: એક નિશ્ચિત બજેટ

એ જ દિવસે અમે ચાર વસ્તુઓ બદલી:

• આખા ખસેડવાના કામ માટે એક મિનિટ. દરેક પગલું, એટલે કદ તપાસવું, પેક કરવું, નવું વર્કસ્પેસ બનાવવું, ટ્રાન્સફર કરવું, અનપેક કરવું અને સરખાવવું, એક જ 60-સેકન્ડના બજેટમાં ચાલે છે. તે પૂરું થાય ત્યારે પ્રોજેક્ટ જૂના વર્કસ્પેસમાં ખુલે છે.
• માત્ર રાહ નહીં, કામ પણ બંધ કરો. અમારી બાજુએ છોડી દેવું પૂરતું નથી, જો આર્કાઇવિંગ હજી એ વર્કસ્પેસની અંદર ચાલી રહ્યું હોય જેનો ઉપયોગ માલિક કરવા જઈ રહ્યા છે. હવે દરેક આર્કાઇવ કમાંડ બજેટ પૂરું થતાં પહેલાં વર્કસ્પેસની અંદર જ બંધ કરવામાં આવે છે. જો નવું વર્કસ્પેસ અમે છોડી દીધા પછી આવે, તો તેને કાઢી નાખવામાં આવે છે.
• માલિકને સફાઈ માટે રાહ ન જોવડાવો. અસ્થાયી આર્કાઇવ કાઢવાનું કામ હવે પૃષ્ઠભૂમિમાં થાય છે.
• દરેક ખોલવા પર ફરી પ્રયાસ ન કરો. જે પ્રોજેક્ટ ખસેડી ન શકાય તેને 24 કલાક માટે છોડી દેવામાં આવે છે, જેથી નિષ્ફળતા દિવસમાં વધુમાં વધુ એક વખત વિલંબ કરે, દરેક ખોલવા પર નહીં.

ત્રીજો પ્રયાસ: તેને જાગવાની પ્રક્રિયામાંથી બહાર કાઢો

તેનાથી સૌથી ખરાબ કિસ્સો એક મિનિટ સુધી મર્યાદિત થયો. પણ એક મિનિટ પણ મિનિટ જ છે, અને અમને સમજાયું કે ખસેડવાનું કામ કોઈના પણ માર્ગમાં હોવું જરૂરી નથી.

હવે 1 GB પર કોઈ નવું વર્કસ્પેસ બનતું નથી. તો આ કોઈ સતત ચાલતી પ્રક્રિયા નથી; તે નિશ્ચિત વર્કસ્પેસોની યાદી પર એક વખતનું કામ છે. તેને જાગવાની અંદર રાખવાથી દરેક ધીમા ખસેડવા માટે એક વાસ્તવિક વ્યક્તિએ કિંમત ચૂકવી, અને કોઈ વર્કસ્પેસ ખસેડી નહીં શકાય એ જાણવાનો એકમાત્ર રસ્તો એ હતો કે કોઈએ હમણાં જ તેની રાહ જોઈ હોય.

તેથી અમે ખસેડવાનું કામ જાગવાની પ્રક્રિયામાંથી સંપૂર્ણપણે કાઢી નાખ્યું. પ્રોજેક્ટ ખોલવાથી પહેલાંની જેમ જ થાય છે. બાકી રહેલા નાના વર્કસ્પેસને હવે એક સુપરવાઇઝ્ડ બેચ તરીકે સંભાળવામાં આવે છે: તેની રાહ કોઈ જોતું નથી, અને જે વર્કસ્પેસ ખસેડી ન શકાય તે બેચના રિપોર્ટમાં દેખાય છે, જ્યાં અમે તેને જોઈ શકીએ, માલિકની સામે નહીં.

અમે શું શીખ્યા

• કદ બદલવું હંમેશાં શક્ય નથી. જ્યારે પ્લેટફોર્મ બનાવતી વખતે કદ નક્કી કરે છે, ત્યારે ડિફોલ્ટ વધારવાથી ફક્ત નવી વસ્તુઓને ફાયદો થાય છે. જૂની વસ્તુઓ માટે યોજના બનાવો.
• "હજી કોઈ વાપરતું નથી" એનો મતલબ હજી પણ કોઈ રાહ જોઈ રહ્યું છે. પ્રોડક્ટમાં પ્રવેશતી વખતે થતું કામ એ કામ છે જે કોઈ વ્યક્તિ જુએ છે.
• વપરાશકર્તાના માર્ગમાં આવતી કોઈ પણ વસ્તુ પર બજેટ મૂકો, અને બજેટ પૂરું થાય ત્યારે કામ બંધ કરો. અમારી બાજુએ ટાઇમઆઉટ કરવું, અને બીજે ક્યાંક કમાંડ ચાલતી રહેવી, સમસ્યાને માત્ર ખસેડે છે.
• એક વખતનું સ્થળાંતર એક વખતના કામમાં હોવું જોઈએ. તેને રોજિંદી ક્રિયાઓની અંદર છુપાવવાથી તેને લખવું સસ્તું પડે છે, પણ ચલાવવું મોંઘું.
• તમારી સેફ્ટી ચેક્સનું પરીક્ષણ કરો. જે સરખામણી કંઈ સરખાવતી જ નથી, તે જે સરખામણી પાસ થઈ છે તેના જેવી જ દેખાય છે.

જો તમે Mythex પર બનાવો છો, તો તમારે કંઈ કરવાની જરૂર નથી: ધ્યેય એટલો જ છે કે મેમરી ખૂટવાને કારણે ઓછા વર્કસ્પેસ બંધ પડે, અને પ્રોજેક્ટ ખોલવાની ગતિ પહેલાં જેટલી જ રહે. વર્કસ્પેસ કેવી રીતે પોઝ અને જાગે છે તે વિશે પ્રાઇવેટ વર્કસ્પેસ વિભાગમાં ડૉક્સમાં સમજાવેલું છે. બીજી એક મેમરી-ક્રેશની વાર્તા માટે, પ્રોગ્રેસ લેબલમાં છુપાયેલો આઉટ-ઓફ-મેમરી ક્રેશ જુઓ.