VPN પર SSHFS પર git status ધીમે ચાલે છે: કામ ખસેડો

200 MB ફાઇલ કૉપિ કરો અને તે ઊડે છે. એ જ ડિરેક્ટરીમાં git status ચલાવો અને રાહ એટલી લાંબી હોય છે કે બીજા કામમાં ધ્યાન જાય. આ બે અવલોકનો વિરોધાભાસી નથી, કારણ કે બલ્ક ટ્રાન્સફર થ્રુપુટ માપે છે જ્યારે Git માપે છે કે તે સેકન્ડમાં કેટલા નાના ફાઇલસિસ્ટમ પ્રશ્નો પૂછી શકે છે, અને માઉન્ટ કરેલું દૂરનું ઝાડ દરેક પ્રશ્નને એક આંટામાં ફેરવે છે. VPN ટ્યુન કરવાથી ખોટા આકારનું કામ બરાબર નહીં થાય.

status કેમ ખોટો માપદંડ છે

Git ને ઘણી ફાઇલો વિશે જાણવું પડે છે: કઈ બદલાઈ છે, કઈ ટ્રૅક થઈ નથી, અને કૅશ કરેલ ઇન્ડેક્સ ડેટા હજી ડિસ્ક પરના ડેટા સાથે મેળ ખાય છે કે નહીં. SSHFS પર આમાંનું દરેક અવલોકન નેટવર્ક કામગીરી હોઈ શકે. અહીં કામનો એકમ ફાઇલોની સંખ્યા છે, મેગાબાઇટ નહીં.

તેથી ક્લોન પછીનું પહેલું status ધીમું છે, અને તેથી બિલ્ડ આઉટપુટથી ભરેલા ઝાડમાં પછીનાં વધુ ધીમાં હોઈ શકે છે. ટ્રૅક ન થયેલી ફાઇલોનું સ્કેનિંગ એવી ડિરેક્ટરીઓમાં ફરે છે જે તમને ન ગમે, અને દરેક પગલું લિંક પર બીજી વિનંતી છે. 40 ms ના માર્ગ પર થોડા હજાર નોંધ ધરાવતું ઝાડ થોડા હજાર આંટામાં ફેરવાય છે. આ હિસાબ ચકાસવા પેકેટ કૅપ્ચરની જરૂર નથી.

ડાઉનલોડ માપદંડ કહે છે લિંક ઠીક છે; હજાર નાની વાંચન આજે બપોરે પૂરી થશે કે નહીં તે કંઈ કહેતું નથી.

કામનું ઝાડ ખસેડો, ટ્યુનિંગ નોબ નહીં

લોકલ ક્લોન કામનું ઝાડ, ઇન્ડેક્સ અને Git કામગીરીને એક જ મશીન પર મૂકે છે. પછી pull એક દૃશ્ય નેટવર્ક પગલું બને છે, દરેક ફાઇલ તપાસ નહીં.

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

જો વર્કસ્પેસ દૂરનું જ રહેવું હોય, તો ત્યાં જ Git ચલાવો

ક્યારેક વર્કસ્પેસ ખસેડી શકાતું નથી: બિલ્ડને એ પર્યાવરણ જોઈએ, ડેટા ઘણો મોટો છે, અથવા નીતિ સ્રોતને હોસ્ટ પર રાખે છે. ત્યારે ફાઇલોની બાજુમાં જ Git અને સંબંધિત ડેવલપમેન્ટ સાધનો ચલાવો, મંજૂર દૂરના શેલ અથવા દૂરના-ડેવલપમેન્ટ પર્યાવરણ દ્વારા. એડિટર લૅપટૉપ પર રહી શકે છે જ્યારે તેનું બૅકએન્ડ કામના ઝાડની બાજુમાં કામ કરે.

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

સિંક એ માલિકો સાથેનો કાર્યપ્રવાહ છે, કૅશ નહીં

સિંક કરેલ વર્કસ્પેસ પુનરાવર્તિત દૂરની વાંચન ઘટાડી શકે છે, પણ તે પારદર્શક કૅશ નથી. તેને દરેક ફેરફાર માટે માલિક, વિવાદ માટે નિયમ, અને જનરેટ થયેલ ફાઇલો વિશે કરાર જોઈએ જે બંને પક્ષ પોતાની માને છે. એ નિયમો વિના ગોઠવણ સુવિધાને બદલે મતભેદ પેદા કરે છે.

તેમના વિના દ્વિદિશ સિંક થયેલ સમસ્યાનો ઉકેલ કરતાં જુદી સમસ્યા પેદા કરે છે, સામાન્ય રીતે એવું મર્જ જે કોઈ કોઈને આપી શકતું નથી. એક જ શેર કરેલા કામના ઝાડ પર બે Git પ્રક્રિયા ચલાવવાનું ટાળો, જ્યાં સુધી તમે સમજતા ન હો કે તેઓ કેવી રીતે સંકલન કરે છે.

પછી ટ્યુન કરો, અને SSH સમજદાર રાખો

ગોઠવણ સાચી થયા પછી બે સેટિંગ બદલે છે કે Git ને કેટલી ફાઇલો વિશે પૂછવું પડે: status.showUntrackedFiles અને core.untrackedCache પાછળનું ટ્રૅક ન થયેલ કૅશ. બંમાંથી કોઈ 40 ms પર દરેક પ્રશ્નનો ખર્ચ બદલતું નથી; તેઓ ફક્ત પ્રશ્નોની સંખ્યા બદલે છે. આંટા સ્થાનિક થાય પછી જ નોબ ફેરવો.

તમને ચીડવતી કમાન્ડનો સમય માપો, એક મોટી ફાઇલ કૉપિ કરતાં માપદંડ પરથી વિચારવાને બદલે, અને સમર્થિત SSH એન્ક્રિપ્શનને અકબંધ રાખો. જૂનું સાઇફર આંટો ટૂંકાવતું નથી; તે બીજી સમસ્યા ઉમેરે છે જે પહેલી કરતાં વધુ ટકે છે. git status સંદર્ભ એક વાર વાંચવા જેવો છે, કારણ કે કમાન્ડ તેના નામ સૂચવે તેના કરતાં ઘણું વધુ કામ કરે છે.