OpenAIમાં Gitની ક્ષમતા વધારવી
Gitની સમગ્ર વ્યવસ્થામાં રોકાણ સાથે એજન્ટના વિશાળ કાર્યપ્રમાણને સંભાળી શકે એવું સ્રોત નિયંત્રણ બનાવવું.
છેલ્લા વર્ષમાં અમારી મોનોરિપોનું કદ અને તેના પરની માંગ આશ્ચર્યજનક ઝડપે વધ્યાં છે. સ્પષ્ટ હતું કે Codex જેટલા મોટા પાયે સમવર્તી કામ શક્ય બનાવે છે તે સંભાળવા અમારી સ્રોત નિયંત્રણ સિસ્ટમને નવી રીતે બનાવવી જરૂરી હતી.
ઇજનેરીનું કોઈ કામ અટકાવ્યા વિના કે અમારી ટીમ Git કેવી રીતે વાપરે છે તે બદલ્યા વિના અમે Git રિપોઝિટરી માટે Pando નામનું નવું બૅકએન્ડ બનાવ્યું. હવે OpenAIની મોનોરિપોમાં સમગ્ર વિકાસકાર્ય Pando પર ચાલે છે. Pando બે મહત્ત્વાકાંક્ષી લક્ષ્યો માટે રચાયું છે: પ્રથમ, વધુ સર્વર ઉમેરીને લેખનની ક્ષમતા વધારવી અને અનેક શાખાઓમાં સમવર્તી પુશ માટે તેને શ્રેષ્ઠ બનાવવી. બીજું, વાંચન થ્રૂપુટ મહત્તમ કરવું, જેથી ક્લાયન્ટ પોતાની ઉપલબ્ધ નેટવર્ક બૅન્ડવિડ્થ સંપૂર્ણ વપરાય એટલી ઝડપે ડેટા ડાઉનલોડ કરી શકે.
Git પ્રોટોકોલ અને ક્લાયન્ટ સાથે સુસંગતતા જાળવીને અમે આ લક્ષ્યો હાંસલ કર્યાં, જેથી અમારા ઇજનેરો અને એજન્ટ તેમની હાલની કાર્યપદ્ધતિમાં સરળતાથી Pando અપનાવી શક્યા. વાસ્તવિક ઉપયોગમાં Pandoએ પુશનો મધ્યક વિલંબ લગભગ પાંચમા ભાગનો કર્યો. હવે તે દરરોજ લગભગ એક પેટાબાઇટ Git ડેટા પહોંચાડે છે.
અહીં અમે નવી સ્રોત નિયંત્રણ સિસ્ટમ બનાવવાનાં કારણો અને Git સાથે સુસંગતતા જાળવવાનું શા માટે પસંદ કર્યું તે સમજાવીશું. અમે અમારી સિસ્ટમની સરખામણી Gitની ક્ષમતા વધારવાના સામાન્ય અભિગમો સાથે કરીશું અને OpenAIની વધતી ક્ષમતાની જરૂરિયાતો પૂરી કરવામાં Pando શા માટે વિશિષ્ટ રીતે સક્ષમ છે તે જણાવીશું. અમે આગળની યોજનાઓ અને એજન્ટના સ્તરે મોટા પાયે કામને ટેકો આપવા Gitમાં અમારું યોગદાન કેવી રીતે ચાલુ રાખીશું તેની પણ ચર્ચા કરીશું.
Codexએ OpenAIમાં વિકાસનું પ્રમાણ અને ગતિ બદલી નાખ્યાં છે, જેથી ઇજનેરો ઘણું વધારે કામ સમાંતર કરી શકે છે. એટલે વધુ શાખાઓ અને પુશ, વધુ મર્જ તથા વિકાસ પર્યાવરણો, સંશોધન કાર્યો અને CIમાંથી વધુ ફેચ અને ક્લોન.
આ માંગ એકબીજાને વધુ વધારે છે. હવે એક ઇજનેર પાસે એકસાથે CI માટે અનેક ફેરફારો તૈયાર હોય છે અને દરેક પુશ એક જ કમિટ મેળવવા અનેક કાર્યો શરૂ કરી શકે છે.
ગયા વર્ષના અંતની આસપાસથી અમારી મોનોરિપોને ટેકો આપતી સિસ્ટમો આ ગતિ જાળવવામાં મુશ્કેલી અનુભવવા લાગી. અમારે ધીમા ફેચ અને પુશ તથા નિષ્ફળ મર્જનો સામનો કરવો પડ્યો. ક્યારેક વિશ્વસનીયતા 90%થી પણ નીચે ગઈ. શું અમે Gitની જ મર્યાદાએ પહોંચ્યા હતા કે મોનોરિપોને સેવા આપવાની અમારી રીતની મર્યાદાએ? કર્નલના પૅચની ઇમેઇલ દ્વારા આપલે કરતા સમુદાયમાંથી Git વિકસ્યું હતું. બે દાયકાથી વધુ સમયથી સૉફ્ટવેર બનાવવાની રીત બદલાતી ગઈ તેમ વિકાસકર્તાઓએ તેમનાં સાધનોને Gitની આસપાસ અનુકૂળ બનાવ્યાં છે. અમારી પોતાની મોનોરિપોમાં અડચણો અનુભવાવા લાગી ત્યારે એ કામને આગળ વધારતા રહેવું અમારા માટે મહત્ત્વનું હતું.
અમને પરિચિત કાર્યપદ્ધતિ જાળવીને બૅકએન્ડ ફરી બનાવવાનો માર્ગ દેખાયો: જુદી શાખાઓના પુશ સમાંતર સંભાળવા અને અનેક વાંચતા ક્લાયન્ટને એકસાથે એક જ ઇતિહાસ આપવો. સ્રોત નિયંત્રણ કાર્યપદ્ધતિના પાયા તરીકે Git રાખવાથી ક્લાયન્ટમાં કરેલા સુધારા OpenAI બહાર પણ ઉપયોગી થઈ શકે. અમે અમારી Gitની નકલ(નવી વિન્ડોમાં ખૂલે છે)માંથી તે સુધારા મૂળ પ્રોજેક્ટમાં આપવા અને વ્યાપક સમુદાય સાથે વહેંચવા માગતા હતા.
સ્રોત નિયંત્રણ સિસ્ટમની ક્ષમતા વધારવાનાં બે મુખ્ય પાસાં છે: જુદી શાખાઓમાં પુશ કરતા ઘણા લેખક ક્લાયન્ટ અને એક જ ઇતિહાસ મેળવતા ઘણા વાચક ક્લાયન્ટ. Pando બંને માટે કાર્યક્ષમતા વધારે છે.
પ્રથમ, Pando દરેક શાખાના અપડેટનું સ્વતંત્ર રીતે સંકલન કરે છે. અસંબંધિત શાખાઓના અપડેટ સમાંતર થઈ શકે છે અને શાખા મેળવતા ક્લાયન્ટને તે આવૃત્તિ માટે જરૂરી ઇતિહાસ મળે છે. તેના બદલામાં, અનેક શાખાઓ જોતો ક્લાયન્ટ તેમને જુદા સમયબિંદુઓની સ્થિતિમાં જોઈ શકે છે.
બીજું, દરેક ક્લાયન્ટ માટે અલગ પૅકફાઇલ બનાવવાને બદલે Pando ફેચમાં પૅકફાઇલનો ફરી ઉપયોગ કરે છે. પૅકફાઇલ એ ઘણા ઑબ્જેક્ટને એકસાથે સંકોચવાનું Gitનું સ્વરૂપ છે. ક્લાયન્ટ પોતાની પાસે પહેલેથી હોય એવા કેટલાક ઑબ્જેક્ટ ફરી ડાઉનલોડ કરી શકે છે, પણ સર્વર ઓછી ગણતરી કરીને અનેક ક્લાયન્ટને એ જ બાઇટ આપી શકે છે.
આ પસંદગીઓથી અમે શાખાઓમાં લેખનની ક્ષમતા વધારી શકીએ છીએ અને કૅશમાંથી વાંચનની વિનંતીઓ પૂરી કરી શકીએ છીએ. આ બંને કેવી રીતે સાથે કામ કરે છે તે સમજવા પહેલાં Git ઇતિહાસ કેવી રીતે સંગ્રહે છે અને મોકલે છે તે જોઈએ.
Gitએ રિપોઝિટરીના બે ભાગને સુમેળમાં રાખવા પડે છે: ઑબ્જેક્ટ અને સંદર્ભ.
Git રિપોઝિટરી ફાઇલોની સ્થિતિ અને તેમને જોડતો ઇતિહાસ ઑબ્જેક્ટના ગ્રાફ તરીકે નોંધે છે. ઑબ્જેક્ટ બ્લૉબ, ટ્રી, કમિટ અથવા ટૅગ હોઈ શકે છે. બ્લૉબમાં એક ફાઇલની સામગ્રી હોય છે. ટ્રી નામોને બ્લૉબ કે અન્ય ટ્રી સાથે સાંકળીને ડિરેક્ટરીનું માળખું બનાવે છે. કમિટ રૂટ ટ્રી અને શૂન્ય કે વધુ પેરન્ટ કમિટ તરફ નિર્દેશ કરે છે, જે તમારી રિપોઝિટરીનો ઇતિહાસ બનાવે છે.
ઑબ્જેક્ટ તેમના પ્રકાર અને સામગ્રીના હૅશથી ઓળખાય છે. ઑબ્જેક્ટ અપરિવર્તનીય પણ છે: બદલાયેલી ફાઇલ નોંધવાથી નવો બ્લૉબ બને છે, જ્યારે ન બદલાયેલી ફાઇલ અને ડિરેક્ટરી હાલના ઑબ્જેક્ટ ફરી વાપરી શકે છે.
શાખાઓ અને ટૅગ એ સંદર્ભો, એટલે કે “રેફ”, છે જે કમિટ તરફ નિર્દેશ કરે છે. શાખા પર કમિટ કરવાથી નવો કમિટ બને છે અને શાખાનો રેફ તેના તરફ નિર્દેશ કરવા અપડેટ થાય છે.
Git ઑબ્જેક્ટ ID દ્વારા એકબીજાનો સંદર્ભ આપે છે: કમિટ ટ્રીનો અને ટ્રી અન્ય ટ્રી તથા બ્લૉબનો. refs/heads/main શાખા C2 કમિટ તરફ નિર્દેશ કરે છે, જેનો પેરન્ટ C1 છે. C1 રૂટ ટ્રી T1 તરફ નિર્દેશ કરે છે, જ્યાં parser.py બ્લૉબ B1નો સંદર્ભ આપે છે. C2 રૂટ ટ્રી T2 તરફ નિર્દેશ કરે છે, જ્યાં parser.py બ્લૉબ B2નો સંદર્ભ આપે છે. બંને રૂટ ટ્રીમાં docs/ એક જ ટ્રી T3નો સંદર્ભ આપે છે. તેની README.md નોંધ બ્લૉબ B3 તરફ અને usage.md બ્લૉબ B4 તરફ નિર્દેશ કરે છે.
Git ઑબ્જેક્ટને “અલગ” અથવા “પૅક કરેલી” સ્થિતિમાં સંગ્રહે છે. અલગ ઑબ્જેક્ટ તેમના ઑબ્જેક્ટ IDથી ઓળખાતી અલગ ફાઇલોમાં સંગ્રહાય છે. પૅક કરેલા ઑબ્જેક્ટ એક પૅકફાઇલમાં સાથે સંગ્રહાય છે, જેથી સમાન ઑબ્જેક્ટને એકબીજાથી થતા તફાવત રૂપે સાચવી શકાય.
Git બ્લૉબને અલગ ફાઇલ તરીકે સાચવી શકે છે અથવા એક બ્લૉબને બીજા સામેના તફાવત રૂપે એન્કોડ કરીને તેમને સાથે પૅક કરી શકે છે.
Gitમાં કોઈ કમિટથી તેના પેરન્ટ, ટ્રી અને બ્લૉબની લિંક અનુસરીને ઑબ્જેક્ટ મળી શકે તો તે ઑબ્જેક્ટ સુધી તે કમિટમાંથી પહોંચી શકાય છે. ફેચ દરમિયાન ક્લાયન્ટ સર્વરને જણાવે છે કે તેને કયા કમિટ જોઈએ છે અને તેની પાસે કયા પહેલેથી છે. સર્વર જોઈતા કમિટમાંથી પહોંચી શકાય તેવા ઑબ્જેક્ટ શોધે છે, ક્લાયન્ટ પાસે પહેલેથી હોવાનું જાણીતું હોય તે બાકાત રાખે છે અને બાકીનાને Git ડિસ્ક પર વાપરે છે તે જ સ્વરૂપની પૅકફાઇલમાં મોકલે છે. સંપૂર્ણ ક્લોનની શરૂઆત કોઈ ઑબ્જેક્ટ વિના થાય છે, તેથી ક્લોન થતા ઇતિહાસમાંથી પહોંચી શકાય તેવા બધા ઑબ્જેક્ટ જોઈએ છે.
પુશ સર્વરને એક કે વધુ રેફ અપડેટ કરવાનું કહીને ઑબ્જેક્ટ વિરુદ્ધ દિશામાં મોકલે છે. સર્વર પાસે પહેલેથી હોય તેવા ઑબ્જેક્ટ મોકલવાનું ટાળવા ક્લાયન્ટ સર્વરે જાહેર કરેલા રેફનો સમૂહ વાપરે છે. તેથી મોકલાતો પૅક હાલના ઑબ્જેક્ટ પર આધારિત હોઈ શકે છે: માત્ર પૅક મળવાથી નવો ઇતિહાસ પુનઃરચી શકાતો નથી.
Git રિપોઝિટરીની પ્રતિકૃતિ બનાવવી એટલે અનેક સર્વર પર ઑબ્જેક્ટ અને સંદર્ભ બંને ઉપલબ્ધ રાખવા. પ્રતિકૃતિ સંદર્ભનું નવું મૂલ્ય આપી શકે તે પહેલાં, તે મૂલ્યમાંથી પહોંચી શકાય તેવા ઑબ્જેક્ટ પણ આપી શકવી જોઈએ. સેવાએ હરીફ સંદર્ભ અપડેટનું પણ સંકલન કરવું પડે છે, એટલે કે એક જ શાખાને એક જ જૂના અંતિમ કમિટથી જુદા નવા કમિટ પર ખસેડવાનો પ્રયાસ કરતા પુશનું. રિપોઝિટરીના બધા લેખન પર એક જ ક્રમ લાદતી સિસ્ટમો અસંબંધિત શાખાઓના પુશને પણ એકબીજાની રાહ જોવડાવી શકે છે.
Pandoની રચના કરતી વખતે અમે Gitથી સ્રોત નિયંત્રણની ક્ષમતા વધારવાના પરંપરાગત અભિગમો તપાસ્યા: એકમાં ત્રણ-તબક્કાના કમિટ (3PC, અનેક નોડ વચ્ચે કમિટનું સંકલન કરતો પ્રોટોકોલ)થી રિપોઝિટરીની પ્રતિકૃતિઓમાં રેફ અપડેટનું સંકલન થાય છે. બીજામાં બ્લૉબ સંગ્રહના શેર કરેલા પૂર્વલેખન લૉગ (WAL, ફેરફાર લાગુ કરતાં પહેલાં લખાતી નોંધ)થી અપડેટનો ક્રમ નક્કી થાય છે.
અમે અનુકરણ કરેલી ત્રણ-તબક્કાના કમિટની રચનામાં Git સેવા ઘણી પ્રતિકૃતિઓ પર રિપોઝિટરીની સંપૂર્ણ નકલ રાખે છે. કોઈ પણ સર્વરને પુશ મળે ત્યારે આવતી પૅકફાઇલની નકલ કરીને બધી પ્રતિકૃતિઓને સમાંતર મોકલાય છે. પુશ પ્રકાશિત કરવા મોટાભાગની પ્રતિકૃતિઓએ રેફ અપડેટ સ્વીકારવો જરૂરી છે. આ સંભાળતું સર્વર સંકલનકર્તા છે. તેની અને દરેક અન્ય પ્રતિકૃતિ વચ્ચે અનેક તબક્કામાં સંદેશાવ્યવહાર જરૂરી છે.
સંદર્ભ અપડેટ સ્વીકારવા દરેક પ્રતિકૃતિ પોતાની રેફની નકલ લૉક કરે છે અને તે હજી ક્લાયન્ટની અપેક્ષા મુજબના કમિટ તરફ નિર્દેશ કરે છે તેની ખાતરી કરે છે. પછી સંકલનકર્તા સ્વીકારનાર પ્રતિકૃતિઓને કમિટ-પૂર્વ સંદેશ મોકલે છે. મોટાભાગની પ્રતિકૃતિઓ કમિટ-પૂર્વ સંદેશ મળ્યાની પુષ્ટિ કરે પછી સંકલનકર્તા તેમને અપડેટ કરવાનું કહે છે. ત્યાર પછી કોઈ પણ અદ્યતન પ્રતિકૃતિ રિપોઝિટરીની પોતાની સ્થાનિક નકલમાંથી શાખાનો નવો અંતિમ કમિટ જાહેર કરી શકે છે.
સંપૂર્ણ પ્રતિકૃતિઓ રાખવાથી સ્થાનિક રીતે વાંચનની વિનંતીઓ પૂરી થઈ શકે છે અને ક્લાયન્ટ ગમે તે પ્રતિકૃતિ પસંદ કરે, તેને બધા સંદર્ભોની સુસંગત સ્થિતિ મળવાની ખાતરી રહે છે. પરિણામે સંદર્ભો એક સમયે એક અપડેટ થાય છે અને દરેક પુશ માટે પ્રતિકૃતિઓ વચ્ચે રેફ અપડેટનું સંકલન કરવા અનેક વાર સંદેશની આપલે જરૂરી બને છે.
જરૂરી બહુમતીની રાહ જોવાને કારણે પુશનો સમય પ્રતિકૃતિની ડિસ્ક કામગીરી અને સંદેશાવ્યવહારના વિલંબ પર આધારિત બને છે. લેખનનું પ્રમાણ વધે તેમ પ્રતિકૃતિઓએ આવતા પૅક અને વાંચનની વિનંતીઓ બંનેને પહોંચી વળવું પડે છે.
અમે અનુકરણ કરેલી WAL-આધારિત રચનામાં Git સેવા સમગ્ર રિપોઝિટરીના અપડેટને ક્રમ આપવા બ્લૉબ સંગ્રહમાં શેર કરેલું મેનિફેસ્ટ વાપરે છે. સર્વરને પુશ મળે ત્યારે તે આવતી પૅકફાઇલ બ્લૉબ સંગ્રહમાં અપલોડ કરે છે અને રિપોઝિટરીની પોતાની સ્થાનિક નકલમાં રેફ અપડેટ તૈયાર કરે છે. પુશ પ્રકાશિત કરવા તે બ્લૉબ સંગ્રહના શેર કરેલા મેનિફેસ્ટમાં એક નોંધ ઉમેરે છે, જે રેફ અપડેટ નોંધે છે અને પૅકફાઇલ તરફ નિર્દેશ કરે છે. પછી Git સર્વર તુલના-અને-બદલી કામગીરીથી મેનિફેસ્ટ અપડેટ કરે છે. આ મેનિફેસ્ટને અવિભાજ્ય રીતે બદલે છે, નહીં તો ફેરફાર નકારે છે. દરમિયાન બીજા લેખક ક્લાયન્ટે તેને અપડેટ કર્યું હોય તો સર્વર વચ્ચેની નોંધો વાંચે છે, પોતાનો રેફ અપડેટ હજી માન્ય છે તે ચકાસે છે અને પહેલેથી અપલોડ કરેલી પૅકફાઇલથી ફરી પ્રયાસ કરે છે.
લેખક ક્લાયન્ટ પોતાની પૅકફાઇલ સમાંતર અપલોડ કરી શકે છે, પણ અસંબંધિત શાખાઓના પુશ માટે પણ એ જ મેનિફેસ્ટ અપડેટ કરવું પડે છે. સફળ તુલના-અને-બદલી માટેના આવવા-જવાના સમયથી રિપોઝિટરી કેટલી વાર નવું મેનિફેસ્ટ પ્રકાશિત કરી શકે તેની મર્યાદા નક્કી થાય છે. ઓછા વિલંબવાળો બ્લૉબ સંગ્રહ આ પગલું ઝડપી બનાવે છે. અપડેટને જૂથમાં ભેગા કરવાથી એક મેનિફેસ્ટ એકસાથે અનેક રેફ અપડેટ કરી શકે છે, પણ તેના માટે અપડેટને કતારમાં રાખવા પડે છે અને વિલંબ વધે છે.
બ્લૉબ સંગ્રહ પૅકફાઇલ સમાંતર મેળવી શકે છે, પણ શેર કરેલા મેનિફેસ્ટના અપડેટ હજી એકબીજા સાથે હરીફાઈ કરે છે. માત્ર બ્લૉબ સંગ્રહની ક્ષમતા વધારવાથી આ અવરોધ દૂર થતો નથી. દરેક પ્રતિકૃતિએ પૅક સ્થાનિક રીતે આપી શકે તે પહેલાં હજી પણ બ્લૉબ સંગ્રહમાંથી તેને વાંચવો અને તેની અનુક્રમણિકા બનાવવી પડે છે. આવતું લેખન આ કામ કરતાં વધુ ઝડપી હોય તો પ્રતિકૃતિઓ પાછળ રહી જાય છે અને ક્લાયન્ટને નવા પુશ કરેલા કમિટ મેળવવા વધુ રાહ જોવી પડે છે.
આ જ પ્રશ્નો અમને Pando તરફ લઈ આવ્યા. Pando એ Git રિપોઝિટરીને સેવા આપતું નવું માળખું છે, જેનો હેતુ એકસાથે પુશ કરતા ઘણા ક્લાયન્ટને સંભાળવા ક્ષમતા વધારવાનો છે. તે આ રીતે કામ કરે છે:
Pando વિકસાવતા પહેલાં અમને લાગતું હતું કે Git સાથે સમાધાન કર્યા વિના અમારી જરૂરિયાતો પૂરી થઈ શકશે. જોકે મોટાભાગની Git સિસ્ટમો જેને અનિવાર્ય માને છે તેવી કેટલીક બાબતોમાં સમાધાન કરવું જરૂરી હતું:
સમગ્ર રિપોઝિટરીમાં સુસંગતતા: બધા રેફની એક જ સમયબિંદુની સુસંગત સ્થિતિ આપવા માટે સમગ્ર રિપોઝિટરીમાં સંકલન જરૂરી છે. બધા રેફ અપડેટને એકસાથે ક્રમ આપતી સિસ્ટમમાં અસંબંધિત શાખાઓના પુશ પણ એક જ સંકલનબિંદુ પર હરીફાઈ કરે છે.
દરેક ક્લાયન્ટ માટે અલગ પૅકફાઇલ: અલગ સ્થાનિક ઇતિહાસ ધરાવતા બે ક્લાયન્ટ એક જ શાખા મેળવે ત્યારે તેમની પાસે પહેલેથી હોય તેવા ઑબ્જેક્ટ ફરી ન મોકલવા માટે સર્વરને દરેક માટે અલગ પૅક બનાવવો પડી શકે છે. આ પ્રતિભાવો બનાવવામાં CPU અને ડિસ્ક I/O ખર્ચાય છે, તેથી મોટી સંખ્યામાં વાંચતા ક્લાયન્ટને સેવા આપવી મુશ્કેલ બને છે.
તેના બદલે, Pando લેખનની ક્ષમતા વધારવા માટે ઓછી કડક સુસંગતતા પદ્ધતિ (કારણાધારિત સુસંગતતા) આપે છે અને વાંચનની ક્ષમતા વધારવા પૅકફાઇલનો ફરી ઉપયોગ કરે છે.
ક્લાયન્ટ કોઈ શાખામાં પુશ કરે ત્યારે Pando આવતી પૅકફાઇલને બ્લૉબ સંગ્રહમાં અપરિવર્તનીય બ્લૉબ તરીકે સાચવે છે. દરેક વખતે શાખા આગળ વધે ત્યારે Pando મેટાડેટા સંગ્રહમાં એક રેફ આવૃત્તિ નોંધે છે, જેમાં નવો અંતિમ કમિટ, તેને આપનાર પૅક અને પૅક જેના પર આધારિત હોય તેવી અગાઉની રેફ આવૃત્તિઓ હોય છે. બ્લૉબ સંગ્રહ અને મેટાડેટા સંગ્રહ બંનેની ક્ષમતા વધુ સર્વર ઉમેરીને વધારી શકાય છે.
Pando પાસેથી કમિટ કે સંદર્ભ મેળવવા માટે ક્લાયન્ટને રેફ આવૃત્તિઓનો સમૂહ (પૅકફાઇલો) ફરી મોકલવો પડે છે. તે મેળવાતી રેફ આવૃત્તિ બનાવનાર ક્લાયન્ટની સ્થિતિ પુનઃરચે છે. આ સમગ્ર રિપોઝિટરીમાં ઓછી કડક સુસંગતતા આપે છે, પણ દરેક રેફના અપડેટ માટે ક્રમિક અમલની સમકક્ષતા જાળવે છે. ક્લાયન્ટ વચ્ચે ટકરાવ માત્ર ત્યારે થાય છે જ્યારે તેઓ એક જ રેફમાં એકસાથે પુશ કરે. અનેક શાખાઓ વાંચતો ક્લાયન્ટ એમ માની શકતો નથી કે તે વાંચનો સમગ્ર રિપોઝિટરીના એક જ સમયબિંદુની સ્થિતિ દર્શાવે છે.
મુખ્ય શાખામાં પુશ કરવાથી એક કે વધુ કમિટ ધરાવતો વધારાનો પૅક ઉમેરાય છે. બાજુની શાખામાં દરેક પુશ સાથે વિષયશાખાના અગાઉના કમિટ ફરી સામેલ થાય છે, જેથી જાહેર કરેલી મુખ્ય શાખાની આવૃત્તિ ધરાવતો ક્લાયન્ટ એક જ પૅકમાં વિષયશાખા મેળવી શકે.
આ કારણાધારિત સુસંગતતાનું એક સ્વરૂપ છે. સંદર્ભ મેળવવા માટે વાંચતો ક્લાયન્ટ તેને બનાવનાર ક્લાયન્ટનો ઇતિહાસ જુએ છે. પુશ દરમિયાન ક્લાયન્ટ અને સર્વર કયા શેર કરેલા ઇતિહાસ પર સંમત થાય તે Pando નિયંત્રિત કરે છે, જેથી ક્લાયન્ટ વધુ સરળતાથી ફરી શેર કરી શકાય તેવી પૅકફાઇલ બનાવે.
તેથી Pando, Git કામગીરી દરમિયાન બધા સંદર્ભોની એક જ સમયબિંદુની સ્થિતિ આપતું નથી કે ક્લોન અથવા ફેચમાં રેફ અપડેટનો સર્વસામાન્ય ક્રમ પણ આપતું નથી. ઉદાહરણ તરીકે, ધારો કે સંપૂર્ણ ક્લોન માટેની વાટાઘાટ દરમિયાન foo અને bar બંને શાખા અપડેટ થાય છે. વાટાઘાટ દરમિયાન એક ક્લાયન્ટને foo આવૃત્તિ 1 પર અને bar આવૃત્તિ 2 પર દેખાય, જ્યારે બીજાને foo આવૃત્તિ 2 પર અને bar આવૃત્તિ 1 પર દેખાય. વ્યવહારમાં વપરાશકર્તા અને એજન્ટ રેફ અપડેટના સર્વસામાન્ય ક્રમ પર નિર્ભર નથી હોતા; તેઓ એક સંદર્ભના અપડેટના ક્રમ પર આધાર રાખે છે.
ત્રણ સુસંગતતા પદ્ધતિઓના આ અનુકરણમાં અમે 1,000 ક્લાયન્ટમાંથી દરેકને અલગ શાખા પસંદ કરીને વારંવાર અનન્ય કમિટ પુશ કરવા ગોઠવીએ છીએ. અમે કુલ વીતેલો સમય અને પુશથી ફેચ સુધીનો વિલંબ માપીએ છીએ. બીજું માપ કાર્યભાર માટે મહત્ત્વનું છે, કારણ કે તે વપરાશકર્તા અને એજન્ટને સહયોગ કરવા અથવા આવૃત્તિ નિયંત્રણ પર આધારિત અન્ય સિસ્ટમ વાપરવા માટે લાગતો આવવા-જવાનો સમય માપે છે. આ અનુકરણમાં સામાન્યથી ઉચ્ચ કક્ષાના વર્ચ્યુઅલ મશીનો અને બ્લૉબ સંગ્રહ સિસ્ટમો સુધીના હાર્ડવેરને આવરી લેવાય છે. આ અનુકરણમાં ત્રણ-તબક્કાના કમિટ માટે અમે સમગ્ર રિપોઝિટરીની સુસંગતતાની શરત હળવી કરી છે.
Simulating Git Server Implementations
Follow each writer through repeated pushes, and separately measure when an independent reader can check out each commit.
Pandoને બીજા બે અભિગમો સાથે સરખાવતું આ અનુકરણ ચલાવો. તેમની સરખામણી જોવા માટે સામાન્યથી ઉચ્ચ કક્ષાના હાર્ડવેર સુધીનું માળખું, ક્લાયન્ટની સંખ્યા અને અન્ય સેટિંગ પસંદ કરો.
અનુકરણમાં ત્રણ-તબક્કાની કમિટ સિસ્ટમની ડિસ્ક સંપૂર્ણ વ્યસ્ત થતાં ભાર હેઠળ લેખન વિલંબ નોંધપાત્ર વધે છે. એ જ કારણથી પૂર્વલેખન લૉગ સિસ્ટમોમાં વાંચન વિલંબ નોંધપાત્ર વધે છે, કારણ કે સર્વર જર્નલમાંથી સમયસર વાંચી શકતા નથી. અમારી મોનોરિપો પરના વાસ્તવિક પરીક્ષણ અને આ અનુકરણ બંનેમાં Pando અનેક હજાર ક્લાયન્ટને ભાર હેઠળ કામગીરી પર અસર કર્યા વિના એકસાથે પુશ કરવા દે છે.
પુશ સંભાળતી વખતે Pando આવતી પૅકફાઇલને સ્થાનિક રિપોઝિટરીમાં ખોલ્યા વિના, બ્લૉબ સંગ્રહમાં સતત મોકલતાં મોકલતાં તેની માન્યતા ચકાસે છે. ક્લાયન્ટ ફેચ શરૂ કરે ત્યારે Pando તેને જોઈતા સંગ્રહિત પૅક પસંદ કરે છે અને ક્લાયન્ટ તેમને ડાઉનલોડ કરે છે. કોઈ સર્વરે સ્થાનિક રિપોઝિટરીમાં પૅકફાઇલ લાગુ કરવાની કે ખર્ચાળ પૅક ખોલવાની અને બનાવવાની કામગીરી કરવાની જરૂર નથી. આ સર્વર મુખ્યત્વે વાટાઘાટ અને પૅકફાઇલની પસંદગી કરે છે, તેથી Pando સર્વર સામાન્ય હાર્ડવેર પર ચાલી શકે છે.
આથી Pando ક્લાયન્ટ, ક્લાયન્ટ અને Pando વચ્ચેના નેટવર્ક તથા બ્લૉબ સંગ્રહ સેવાની મર્યાદા સુધી ક્ષમતા વધારી શકે છે. પૂરતી ક્ષમતા હોય ત્યારે સ્વતંત્ર શાખાઓ પર કામ કરતા ક્લાયન્ટ પોતાના કનેક્શનની મહત્તમ ઝડપે પૅક મોકલી કે મેળવી શકે છે. તે ઝડપે વધુ ક્લાયન્ટને સેવા આપવા અમે Pando સર્વર ઉમેરી શકીએ છીએ અને સાથે મેટાડેટા તથા બ્લૉબ સંગ્રહની ક્ષમતા વધારી શકીએ છીએ.
Pushing and Fetching a Branch in Pando
Pando stores the writer’s packfile in blob storage and records the ref version in metadata service. On fetch, Pando selects the packs the reader needs, and Express serves them.
એજન્ટ સ્થાનિક રીતે ફાઇલો સંપાદિત કરીને કમિટ બનાવે છે અને git push ચલાવે છે. તે શાખા અપડેટ કરવા આ ફેરફારોની પૅકફાઇલ બનાવે છે. Pando પૅક મેળવે છે અને તેને સતત પ્રવાહમાં બ્લૉબ સંગ્રહમાં મોકલે છે. એક જ વાર ડિકોડ કરીને આવતા પુશની માન્યતા ચકાસ્યા પછી, Pando બહુ-કી વ્યવહારથી અમારા મેટાડેટા સંગ્રહમાં રેફ આવૃત્તિ નોંધે છે અને રેફ નિર્દેશકને અવિભાજ્ય રીતે અપડેટ કરે છે. આથી Pando “પોતે લખેલું તરત વાંચી શકવાની” સુસંગતતા આપી શકે છે. આ સમગ્ર લેખન કામગીરી માટે મેટાડેટા વાંચન અને લેખન જરૂરી છે.
બીજો ક્લાયન્ટ શાખા મેળવે ત્યારે Pando તેની પાસે પહેલેથી રહેલા ઇતિહાસના આધારે સંગ્રહિત પૅકનો સમૂહ પસંદ કરે છે. આ કામગીરી માટે મેટાડેટા વાંચન જરૂરી છે. અહીં એ ક્લાયન્ટ પાસે રહેલી અને તેને જોઈતી સ્થિતિ વચ્ચે રેફ આવૃત્તિઓમાં સૌથી ટૂંકું અંતર છે. સર્વર પૅકફાઇલના URI આપે છે અને ક્લાયન્ટ તેમને Express સેવા મારફતે ડાઉનલોડ કરે છે, જે પ્રાદેશિક કૅશમાં પૅકફાઇલ સંગ્રહે છે.
આ રચના Pandoના માળખાની ત્રણ મુખ્ય સેવા પર આધારિત છે: પુશ, ફેચ અને કૉમ્પેક્શન.
ક્લાયન્ટ પુશ કરે ત્યારે પરંપરાગત Git સર્વર પોતાનાં બધાં પત્તાં બતાવતા પોકરના ખેલાડીની જેમ પોતાની દરેક શાખા ક્લાયન્ટને બતાવે છે. પછી ક્લાયન્ટ કમિટ, ટ્રી અને બ્લૉબ ભેગાં કરીને એવી પૅકફાઇલ બનાવે છે જેમાં સર્વર પાસે પહેલેથી હોવાનું તેને જાણીતું હોય તેવા ઑબ્જેક્ટ સામેલ નથી હોતા.
વધુ રેફ જાહેર કરવાથી પુશ નાનો બની શકે છે. પણ તેથી પૅકનો ફરી ઉપયોગ કરવો મુશ્કેલ પણ બની શકે છે, કારણ કે મોકલનારે છોડેલા ઑબ્જેક્ટ બીજા ક્લાયન્ટ પાસે ન પણ હોય.
Pando જુદો અભિગમ અપનાવે છે. પોતાનાં બધાં પત્તાં બતાવવાને બદલે તે ક્લાયન્ટને માત્ર પસંદ કરેલી શાખાઓ જાહેર કરે છે. આ બે કારણસર કરવામાં આવે છે:
દરેક રેફની સુસંગત સ્થિતિ આપવી ખર્ચાળ છે. લાખો શાખાઓ હોય ત્યારે માત્ર રેફની જાહેર કરાતી માહિતી જ 100 MiBથી વધી શકે છે. આ આપવા માટે દરેક સર્વરે અદ્યતન મૅપિંગ જાળવવું પડે, જેમાં સંકલનનો નોંધપાત્ર વધારાનો ભાર આવે છે અથવા રેફની સંખ્યા સાથે વધતી ડેટાબેઝ ક્વેરી કરવી પડે.
ક્લાયન્ટને રેફનો માત્ર ઉપસમૂહ આપવાથી તે એવો પૅક બનાવે છે જે ફક્ત સર્વરે સ્પષ્ટપણે બાકાત રાખવાની મંજૂરી આપેલા ઑબ્જેક્ટ પર આધાર રાખે છે. આધારોની નોંધ રાખવાથી Pando એક પુશમાં ક્લાયન્ટે બનાવેલી પૅકફાઇલને પછીના ફેચના પ્રતિભાવ તરીકે આપીને ફરી વાપરી શકે છે.
Git સર્વર વધુ રેફ જાહેર કરે તેમ પુશ કરતા ક્લાયન્ટ પાસે ઑબ્જેક્ટ બાકાત રાખવા વધુ સ્રોત મળે છે, જેથી તેઓ નાના પૅક બનાવી શકે છે. જોકે આ પૅકફાઇલ ફરી વાપરવા માટે સર્વરે ખાતરી કરી શકવી જોઈએ કે ફેચ કરતા ક્લાયન્ટ પાસે તેના બધા આધાર છે. નહીં તો પૅકફાઇલમાં ક્લાયન્ટને જોઈતા ઑબ્જેક્ટ છૂટી જઈ શકે છે.
બીજી તરફ, Git સર્વર કોઈ રેફ જાહેર જ ન કરે તો ક્લાયન્ટ રિપોઝિટરીનો સંપૂર્ણ ઇતિહાસ ધરાવતી પૅકફાઇલ બનાવે. તે પૅકફાઇલ કોઈ પણ બીજો ક્લાયન્ટ વાપરી શકે, પણ તેની મોટી કિંમત એ છે કે કોઈ પણ શાખા મેળવવી વ્યવહારમાં સંપૂર્ણ ક્લોન જેટલી ભારે બને.
વધુ રેફ જાહેર કરવાથી પૅકફાઇલ નાની બને છે. માત્ર એક રેફ જાહેર કરવાથી જ કદમાં મોટાભાગનો ઘટાડો થઈ શકે છે.
ડિફૉલ્ટ રીતે, ક્લાયન્ટ નવી સુવિધા-શાખા પુશ કરે ત્યારે Pando આધાર તરીકે માત્ર નિર્ધારિત મુખ્ય શાખા જાહેર કરે છે. આથી રિપોઝિટરીમાં શાખાઓ વધવા છતાં જાહેર થતી માહિતીનું કદ એકસરખું રહે છે, પરંતુ કેટલીક બાંધછોડ કરવી પડે છે. ઇજનેર એક જ શાખામાં ઘણી વાર પુશ કરે અથવા એક સુવિધા-શાખા પર બીજી બનાવે ત્યારે ક્લાયન્ટે મુખ્ય શાખાની બહારનું બધું ફરી મોકલવું પડે છે.
આથી શાખાના ક્રમિક પુશ મોટા બને છે, તેમાં કદાચ બિનજરૂરી રીતે પુનરાવર્તિત ઑબ્જેક્ટ હોય છે અને ક્લાયન્ટની વધારાની બૅન્ડવિડ્થ વપરાય છે. અમારી મોનોરિપોમાં આ રીતે બનેલી પૅકફાઇલનું સરેરાશ કદ 20 KiBથી ઓછું અને 99મો પર્સેન્ટાઇલ 3 MiBથી ઓછો હતો. અમારા માટે આ વાજબી સમાધાન હતું, કારણ કે જાહેર કરેલી મુખ્ય શાખાનો ઇતિહાસ પહેલેથી ધરાવતો વાચક ક્લાયન્ટ એ એક જ પૅકફાઇલથી શાખા મેળવી શકે છે.
ક્લાયન્ટને જાહેર કરવાના રેફ પસંદ કર્યા પછી Pando પુશ સ્વીકારે છે અને પોતાનો મેટાડેટા સંગ્રહ અપડેટ કરે છે. Pando મેટાડેટા અપડેટને તત્કાળ પૂર્ણ થતા અને પાછળથી થતા ભાગમાં વહેંચે છે. તત્કાળ પૂર્ણ થતો મેટાડેટા અપડેટ સુનિશ્ચિત કરે છે કે ક્લાયન્ટ નવા અપડેટ થયેલા કમિટને તરત મેળવી શકે. તે નવી રેફ આવૃત્તિ લખે છે અને રેફ નિર્દેશકનું મૅપિંગ તેના પર અપડેટ કરે છે. તેમાં નવો અંતિમ કમિટ, પૅકફાઇલની વાટાઘાટમાં વપરાયેલા આધાર અને પુશ કરેલી પૅકફાઇલની લિંક સંગ્રહાય છે.
સાથે જ એ જ વ્યવહારમાં પાછળથી કરવાનું કામ પણ નોંધાય છે, જેમ કે કૉમ્પેક્શનનું સમયનિર્ધારણ. ખૂબ મોટા પુશ માટે કમિટનો માત્ર ઉપસમૂહ તત્કાળ લખાય છે. આથી પુશનું કદ ગમે તે હોય, મેટાડેટા સંગ્રહમાં વાંચન અને લેખનની સંખ્યા સ્થિર રાખી શકાય છે.
મહત્ત્વની વાત એ છે કે Pando સર્વર અસંબંધિત રેફના પુશ સ્વતંત્ર રીતે સ્વીકારી શકે છે. માત્ર રેફ નિર્દેશકની કી માટે હરીફાઈ થાય છે. અમે તેને અવિભાજ્ય તુલના-અને-બદલી જેવી કામગીરીથી સુરક્ષિત રાખીએ છીએ. Pando સર્વર, મેટાડેટા સંગ્રહના ક્ષમતા એકમો અથવા બ્લૉબ સંગ્રહ ઉમેરીને અમે લેખન થ્રૂપુટ વધારી શકીએ છીએ.
ક્લાયન્ટ ફેચ કરે ત્યારે સર્વરને કમિટ IDના બે સમૂહ આપે છે, જે પ્રોટોકોલમાં have અને want તરીકે ઓળખાય છે. પરંપરાગત Git સર્વર ક્લાયન્ટ પાસેના અને તેને જોઈતા કમિટમાંથી પહોંચી શકાય તેવા ઑબ્જેક્ટના સમૂહોનો તફાવત ગણે છે, તે ઑબ્જેક્ટને સંકોચે છે અને પરિણામ ક્લાયન્ટને મોકલે છે. આ કામગીરી ઝડપી બનાવવા ઓપન-સોર્સ Git સર્વર પાસે વિવિધ સ્થાનિક અનુક્રમણિકાઓ હોવા છતાં, આ પૅકફાઇલ બનાવવી ખર્ચાળ થઈ શકે છે અને સામાન્ય રીતે તેમનું અસરકારક કૅશિંગ મુશ્કેલ હોય છે.
તેના બદલે Pando પુશ વખતે નોંધાયેલા કમિટ મૅપિંગથી ક્લાયન્ટના have અને want શોધે છે અને તેમને તે કમિટ ધરાવતી રેફ આવૃત્તિઓના સમૂહ સાથે સાંકળે છે. તે દરેક રેફ આવૃત્તિ Pandoને અગાઉ મળેલી પૅકફાઇલ સાથે જોડાયેલી હોય છે. સર્વર તેના આધારે ક્લાયન્ટની જરૂરિયાત નક્કી કરે છે અને તેને જોઈતા ઑબ્જેક્ટને આવરી લેતી પૅકફાઇલ પસંદ કરે છે.
Planning fetches in Pando
Pando compares what a client has with what it wants, then selects the stored packfiles needed—including any missing branch dependencies.
Fetch 27 trunk packs.
Select a branch to include its trunk dependencies.
Pando, Git પ્રોટોકોલમાં ક્લાયન્ટ પાસે રહેલા અને તેને જોઈતા કમિટને રેફ આવૃત્તિઓના ક્રમ સાથે સાંકળે છે. બાજુની શાખા જોઈતી હોય તો મુખ્ય શાખામાં તેના આધારબિંદુઓ સુધીનો ઇતિહાસ પણ જોઈએ.
Git પ્રોટોકોલ ક્લોન કે ફેચ વખતે HTTP પ્રતિભાવમાં માત્ર એક જ પૅકફાઇલ મોકલવા દે છે. પરંતુ Git પ્રોટોકોલની ઓછી જાણીતી સુવિધા packfile-uri સર્વરને વધારાના પૅક અલગથી ડાઉનલોડ કરવા માટે લિંક આપવા દે છે. Pando ફક્ત આ રીત વાપરે છે અને પ્રતિભાવમાં ખાલી પૅકફાઇલ મોકલે છે. આ સુવિધાને ટેકો આપવા OpenAIએ મૂળ પ્રોજેક્ટમાં packfile-uriના અનેક સુધારાનું યોગદાન આપ્યું છે.
OpenAIની સિસ્ટમો ઘણા ભૌગોલિક પ્રદેશોમાં ચાલે છે, તેથી અમે દરેકમાં સ્થાનિક કૅશ સાથે Pando ક્લસ્ટર જાળવીએ છીએ. પૅક પહોંચાડતી Express સેવા અમારા બ્લૉબ સંગ્રહને કૅશ કરે છે અને બીજી સેવા મેટાડેટા સંગ્રહને કૅશ કરે છે. આ કૅશથી Pando કમિટ ID માટેની વિનંતી અથવા રેફના વિશેષ વાંચનની વિનંતી સંપૂર્ણપણે તે ક્લસ્ટરની કૅશ કરેલી સ્થિતિમાંથી પૂરી કરી શકે છે. પૅકફાઇલની વિનંતીઓ Express સર્વર તરફ મોકલવા અમે સુસંગત હૅશિંગ વાપરીએ છીએ અને 99%થી વધુ વિનંતીઓને કૅશમાંથી જવાબ મળે છે.
આ કૅશ વ્યવસ્થા અત્યંત ઊંચું થ્રૂપુટ આપે છે અને ક્લાયન્ટ તથા Pando વચ્ચેના નેટવર્કની સંપૂર્ણ ક્ષમતા વાપરી શકે છે. આ પૅકફાઇલ URI અને સ્થાનિક કૅશથી અમે ચકાસ્યું છે કે માત્ર ક્લાઉડ પ્રદાતાના પ્રમાણભૂત વર્ચ્યુઅલ મશીન વાપરીને પણ ક્લોન અને ફેચ કામગીરી 10 Gbps નેટવર્ક લિંકની સંપૂર્ણ ક્ષમતા વાપરે છે.
મોટાભાગના Git સર્વરમાં વધતી રિપોઝિટરીની કામગીરી જાળવવા ફરી પૅકિંગ અને બિનજરૂરી ડેટાની સફાઈ જરૂરી છે. બંને પગલાં જગ્યા ખાલી કરે છે, પણ તેમાં ઘણી ગણતરી અને I/O જરૂરી છે.
OpenAIની મોનોરિપો જેવી ઝડપથી બદલાતી રિપોઝિટરીમાં છેલ્લા ફેચ પછીના દરેક પુશ માટે અલગ પૅકફાઇલ URI મોકલવો વ્યવહારુ નથી. પોતાની મુખ્ય શાખાને અદ્યતન કરવા ક્લાયન્ટે દરરોજ હજારો પૅકફાઇલ ડાઉનલોડ કરવી પડે.
તેના બદલે Pando આ વધારાનો ભાર ઘટાડવા બેકગ્રાઉન્ડમાં પૅક ભેગા કરે છે. તેની રચના લૉગ-આધારિત મર્જ-ટ્રીના કૉમ્પેક્શન જેવી છે. દરેક પુશથી Pando જેને “L0” પૅકફાઇલ કહે છે તે બને છે. તે Pando મોકલી શકે તેવો ડેટાનો સૌથી નાનો એકમ છે. સમય જતાં પૃષ્ઠભૂમિમાં ચાલતી પ્રક્રિયાઓ આ પૅકફાઇલને રેફ આવૃત્તિઓનો ક્રમ આવરી લેતા આવરણોમાં ભેગી કરે છે, જે L0થી ગુણોત્તર પ્રમાણે મોટાં થાય છે. આજે અમારી મોનોરિપો L4 સુધીનાં પૅકફાઇલ આવરણો વાપરે છે.
આ આવરણો બે હેતુ પૂરા કરે છે. આવરણ પૂરતું ભરાય પછી કૉમ્પેક્શન પ્રક્રિયા તેને હાથમાં લઈને એક જ પૅકફાઇલ બનાવે છે. પૅકફાઇલની અંદરના ઑબ્જેક્ટ ફરી ગોઠવવાથી સંકોચનનો ગુણોત્તર સુધરે છે. સાથે તે રેફ આવૃત્તિઓ પર સ્કિપ લિસ્ટ તરીકે કામ કરીને ફેચની વાટાઘાટની કામગીરી પણ સુધારે છે. દરેક સ્તરની અનુક્રમણિકા એકસાથે તપાસીને Pando લઘુગણકીય સમયમાં ક્લાયન્ટને મોકલવાના પૅક પસંદ કરી શકે છે. આ પૅકફાઇલ આવરણો ફરી પૅક થયાં હોય કે નહીં, ફેચ આયોજન વધુ કાર્યક્ષમ બનાવે છે અને Pando માટે થ્રૂપુટ તથા વિલંબની જરૂરિયાતો ઘટાડે છે.
Compaction in Pando
Small packfiles are grouped into larger covers across levels, improving compression and speeding up fetches.
કૉમ્પેક્શન બેકગ્રાઉન્ડમાં અનેક રેફ આવૃત્તિઓની પૅકફાઇલ ભેગી કરે છે, જેથી ઓછી ફાઇલથી વધુ કાર્યક્ષમ ફેચ શક્ય બને છે.
ઘણા Git સર્વરથી વિપરીત, અહીં દરેક સ્તરે પૅકફાઇલ રાખવામાં આવે છે; તેને કાઢી નાખવામાં કે બિનજરૂરી માની સાફ કરવામાં આવતી નથી. ક્લાયન્ટ ફેચમાં જણાવે તે have અને wantના આધારે, દરેક સ્તરના પૅક સતત સેવા આપવા વપરાય છે. Pandoને API તરીકે વાપરતા ક્લાયન્ટ માટે પૅકફાઇલમાંથી મનસ્વી ઑબ્જેક્ટ વાંચતી વખતે સામાન્ય રીતે L4 કરતાં L0માંથી ઓછો ડેટા વાંચવો પડે છે, કારણ કે તેમાં ઑબ્જેક્ટ સંકોચાયેલો હોવાની સંભાવના ઓછી હોય છે.
Pandoમાં કૉમ્પેક્શન ક્લાયન્ટને મોકલાતા ડેટાનું કુલ કદ નોંધપાત્ર ઘટાડે છે. ઉપરાંત ક્લાયન્ટ જેટલો પાછળ હોય તેની સરખામણીએ પૅક આયોજનનો ખર્ચ રેખીય કરતાં ધીમી ગતિએ વધે છે. મોટી અને ઝડપથી બદલાતી રિપોઝિટરી માટે આ ખાસ મહત્ત્વનું છે. સૉફ્ટવેર વિકાસમાં આવી રિપોઝિટરીઓ હવે સામાન્ય બનશે એવી અમારી અપેક્ષા છે.
અમે Codex સાથે Pando બનાવ્યું અને શરૂઆતથી વાસ્તવિક ઉપયોગ સુધી માત્ર 10 અઠવાડિયામાં પહોંચ્યા. Pandoનો મુખ્ય ભાગ એક જ ઇજનેરે રચ્યો, એજન્ટની ટીમોએ અમલમાં મૂક્યો અને થોડાક ઇજનેરોએ ઉપયોગમાં તૈનાત કર્યો. Pandoએ આ વર્ષના એપ્રિલમાં વાસ્તવિક ઉપયોગની વિનંતીઓ સંભાળવાનું શરૂ કર્યું. તે OpenAIમાં વપરાતાં સ્રોત નિયંત્રણ વ્યવસ્થાપન સાધનોની મોટી સિસ્ટમનો એક ભાગ છે.
Pandoની રચના ચકાસવા અમે વિવિધ પ્રકારના અભિગમો અપનાવ્યા. અમે સૉફ્ટવેરના વધુ સુરક્ષિત પાયા બનાવવાના અમારા સિદ્ધાંતો લાગુ કર્યા. આ સાવ નવો પ્રોજેક્ટ હોવાથી અમે જૂની નિર્ભરતાઓ વિના Rustમાં Pando બનાવવાનું પસંદ કર્યું. અમે સુસંગતતા પરીક્ષણોનો સમૂહ લખ્યો, જેથી એજન્ટ પોતાના ફેરફારોને Gitના પ્રમાણભૂત વર્તન સામે ચકાસી શકે. અમે નિશ્ચિત પરિણામ આપતા અનુકરણ પરીક્ષણની કાર્યપ્રણાલીઓ પણ વિકસાવી. તેનાથી સિસ્ટમના અચલ નિયમો અને ગુણધર્મો ચકાસી શક્યા તથા વાટાઘાટ અને પૅક આયોજનમાં સૂક્ષ્મ સમયક્રમજન્ય ટકરાવો અને પાછળથી આવેલી ખામીઓ શોધીને ઘટાડી શક્યા.
ઘણા મોડલોએ આ સિસ્ટમમાં યોગદાન આપ્યું. નવા મોડલ ઉપલબ્ધ થયા તેમ અમે તેમનો ઉપયોગ Pandoની કામગીરી અને વિશ્વસનીયતા સુધારવા કર્યો. GPT‑6 Astra વાપરીને એજન્ટોએ Lean અને TLA+માં “Pandoનો સિદ્ધાંત” ઔપચારિક રીતે લખ્યો. તેનો ઉપયોગ અમે અમલીકરણની ખામીઓ શોધવા અને સુધારવા તથા સિસ્ટમના ગુણધર્મો સાબિત કરવા કર્યો. Pandoમાં અપવાદરૂપ પરિસ્થિતિઓ શોધવા અને સુધારવા અનેક અવિરત સત્રો સેંકડો કલાક ચાલ્યાં. અમે Daybreak-સક્ષમ મોડલથી Git અને Pandoની સુરક્ષાને પડકારવા ચોવીસે કલાક એજન્ટ પણ ચલાવીએ છીએ.
શરૂઆતમાં અમે Pandoને હાલની સ્રોત નિયંત્રણ સિસ્ટમ માટે વાંચન અને લેખન પસાર કરતી પ્રોક્સી તરીકે તૈનાત કર્યું. આથી Pando અને અગાઉની સિસ્ટમને સુમેળમાં રાખી શક્યા અને સેવા બંધ કર્યા વિના વિનંતીઓ સુરક્ષિત રીતે Pando પર ખસેડી શક્યા.
કૅશિંગ રચનાના ભાગરૂપે Pando વિનંતીઓ આગળ મોકલતાં પહેલાં પુનરાવર્તિત વિનંતીઓ દૂર કરી શકે છે અને તેમને ભેગી પણ કરી શકે છે. આથી એક પછી એક સિસ્ટમ Pando પર ખસેડતી વખતે અમે હાલનાં સાધનોને સારી રીતે કાર્યરત રાખી શક્યા. વધુ કાર્યભાર Pando પર ખસેડ્યો તેમ તેમના પુશથી Pandoની કૅશ ભરાતી ગઈ અને અમારા અગાઉના બૅકએન્ડની વિશ્વસનીયતા સુધરી.
Pando વાપરતી વખતે કામગીરી સુધારવા અમે Gitનું અમારું જાહેર વિતરણ વિકાસકર્તાઓના કમ્પ્યુટર પર અને ChatGPT ડેસ્કટૉપ ઍપમાં આપવાનું શરૂ કર્યું. ક્લાયન્ટને તબક્કાવાર Pando પર ખસેડવા અમે Git CLIની આસપાસનું આંતરિક આવરણ વાપર્યું. અમે ફેરફારની વિનંતીઓ, કોડ સમીક્ષા અને સ્વચાલન માટેના API સંભાળવા અન્ય અનેક સાધનો બનાવ્યાં. Gitની વિનંતીઓ સાથે અમે જૂના API, વેબહૂક અને રિપોઝિટરી ડાઉનલોડ પર આધારિત સેંકડો એકીકરણો પણ ખસેડ્યાં.
Codexએ પોતે વિકાસકર્તા અને ટીમોને આ પરિવર્તન કરવામાં મદદ કરી. અમે હાલના ચેકઆઉટ તૈયાર કરવા અને એજન્ટને નવી સિસ્ટમ વાપરવામાં માર્ગદર્શન આપવા કૌશલ્યો બનાવ્યાં. પરિણામે વિકાસકર્તાઓ ફક્ત Codexને તેમનાં વિકાસ પર્યાવરણો અને સેવાઓ ખસેડવાનું કહી શકતા હતા.
Pando પર સ્વિચ કરવાથી મર્જની વિશ્વસનીયતા સુધરી અને પુશનો સરેરાશ વિલંબ લગભગ 80% ઘટ્યો.
Pando માત્ર થોડાક CPU કોર વડે દરરોજ એક પેટાબાઇટ Git ડેટા પહોંચાડી શકે છે. Pandoએ એક જ કલાકમાં 57 ટેરાબાઇટથી વધુ Git પૅક પૂરા પાડ્યા છે, જેમાં 99%થી વધુ બાઇટ સ્થાનિક ડિસ્ક કૅશમાંથી આવ્યા હતા.
પૅકનો ફરી ઉપયોગ કરવાથી અનેક ક્લાયન્ટ એક જ રિપોઝિટરીનો ઇતિહાસ ડાઉનલોડ કરી શકે છે અને સેવા આપતા નોડ પર બહુ ઓછી ગણતરી કરવી પડે છે. આ ઉદાહરણ એક રિપોઝિટરીનું છે, પણ Pando ઘણી વધુ રિપોઝિટરી સંભાળવા રચાયું છે. માંગ વધે તેમ અમે ડેટા પહોંચાડવાની અને Git વાટાઘાટની ક્ષમતા સ્વતંત્ર રીતે વધારી શકીએ છીએ.
Git પ્રોટોકોલ અને ક્લાયન્ટ પર Pando બનાવવાથી અમને Gitની પોતાની ખામીઓ અને તેની કામગીરી સુધારવાની તકો ઓળખવામાં મદદ મળી.
ઉદાહરણ તરીકે, Pando ફરી વાપરી શકાય એવા પૅક સીધા ક્લાયન્ટને આપે છે, તેથી તે પૅક ડાઉનલોડ કરવા અને તેમની અનુક્રમણિકા બનાવવી સિસ્ટમને ઝડપી અને વિશ્વસનીય બનાવવાનું મુખ્ય અંગ બન્યું. આ કામથી સમવર્તી ડાઉનલોડ, અધવચ્ચે અટકેલા ટ્રાન્સફર પછીની સફાઈ અને પહેલેથી પૂર્ણ થયેલા ડાઉનલોડ ફરી શરૂ કરવામાં અપવાદરૂપ પરિસ્થિતિઓ બહાર આવી. અમે તે કિસ્સા સુધાર્યા, ફેચ માટે હાલનો પૅક સ્વીકારતી વખતે માન્યતા ચકાસણીઓ ઉમેરી અને તે કામ મૂળ પ્રોજેક્ટમાં પરત આપ્યું.
સમય અને બૅન્ડવિડ્થ ક્યાં વપરાય છે તે પણ જાણવું હતું. તેથી અમે packfile-uri ડાઉનલોડ માટે ટ્રેસિંગ અને પૅક બનાવતી વખતે બાઇટની ગણતરી ઉમેરી, જેથી ધીમા ફેચમાં સમય પૅક બનાવવામાં જાય છે કે મોકલવામાં તે સરળતાથી જાણી શકાય.
OpenAIના Git બિલ્ડ(નવી વિન્ડોમાં ખૂલે છે)માં ક્લાયન્ટ સ્વતંત્ર પૅક સમાંતર ડાઉનલોડ કરી શકે છે અને તેમની અનુક્રમણિકા બનાવી શકે છે. અમે “સ્પષ્ટપણે ઉપલબ્ધ કમિટ”નો ખ્યાલ ઉમેર્યો, જેથી સર્વર શાખાનો હાલનો અંતિમ કમિટ અને પુશ કરતો ક્લાયન્ટ પોતાના પૅકમાંથી બાકાત રાખી શકે તે ઇતિહાસ અલગથી જાહેર કરી શકે. Pando પર આથી ક્લાયન્ટ --force-with-lease વડે સુવિધા-શાખા આગળ વધી નથી તેની ખાતરી કરી શકે છે અને માત્ર મુખ્ય શાખાના આધારે તેનો પૅક બનાવી શકે છે. પછી મુખ્ય શાખાનો તે ઇતિહાસ ધરાવનાર કોઈ પણ એ જ પૅકથી શાખા મેળવી શકે છે.
આમાંના કેટલાક સુધારા મૂળ Gitમાં પહેલેથી સામેલ છે અને બીજા ઘણા અમારી જાહેર રિપોઝિટરીમાં છે. આ સુધારા Pando બહાર પણ ઉપયોગી બને તે માટે અમે Git સમુદાય સાથે કામ ચાલુ રાખ્યું છે. અમારા જાહેર પૅચ ટ્રૅકર(નવી વિન્ડોમાં ખૂલે છે)માં તમે આ કામની પ્રગતિ જોઈ શકો છો.
Git રિપોઝિટરીની ક્ષમતા વધારવા અંગેની પરંપરાગત સમજ પર પુનર્વિચાર કરીને, Pando અમને અમારા ઇજનેરો અને એજન્ટની હાલની Git કાર્યપદ્ધતિ બદલ્યા વિના મોનોરિપોની ક્ષમતા વધારવા દે છે. અમારી મોનોરિપોમાં Pandoએ વધુ કામ સમાંતર કરવાનું શક્ય બનાવ્યું છે, મર્જની વિશ્વસનીયતા સુધારી છે અને કોડના ફેરફાર પ્રકાશિત કરવાનો સમય ઘટાડ્યો છે. મોનોરિપો ઉપરાંત અમે OpenAIમાં Pandoના બીજા ઉપયોગો પણ શોધી રહ્યા છીએ, જેમાં મોટી સંખ્યામાં એજન્ટને શેર કરેલી Git રિપોઝિટરી પર સહયોગ કરવો પડે તેવા કાર્યભારનો સમાવેશ થાય છે.
ઇજનેરો અને એજન્ટ વધુ સૉફ્ટવેર બનાવશે તેમ OpenAI બહારની વધુ ટીમોને સ્રોત નિયંત્રણમાં અમને નડેલી મર્યાદાઓનો સામનો કરવો પડશે. અમે હાલમાં Pandoને શક્ય બનાવતી ટેક્નોલોજી અમારા વપરાશકર્તાઓ સાથે શેર કરવાના માર્ગો શોધી રહ્યા છીએ.
Pando, Git રિપોઝિટરીના વપરાશકર્તા અને સંચાલકોના બે દાયકાના અનુભવ પર આધારિત છે. અમે Pando વિકસાવવાનું ચાલુ રાખીશું અને ઓપન-સોર્સ Git સમુદાય સાથે મળીને વ્યાપક Git વપરાશકર્તાવર્ગને લાભ થાય તેવા સુધારા શેર કરીશું.
