git status VPN-ის გავლით SSHFS-ზე ძვრება: სამუშაო გადაიტანეთ

დააკოპირეთ 200 MB ფაილი და ის დაფრინავს. გაუშვით git status იმავე საქაღალდეში და ლოდინი საკმარისად გრძელია, რომ სხვა რამეზე გადაიტანოთ ყურადღება. ეს ორი დაკვირვება არ ეწინააღმდეგება ერთმანეთს, რადგან მასობრივი გადაცემა ზომავს გამტარუნარიანობას, ხოლო Git ზომავს, რამდენი პატარა კითხვა შეუძლია ფაილურ სისტემას წამში, და მიმაგრებული დისტანციური ხე ყოველ კითხვას მოგზაურობად აქცევს. VPN-ის მორგება არ გამოასწორებს არასწორად ფორმირებულ დატვირთვას.

რატომ არის status არასწორი საზომი

Git-მა ბევრი ფაილის შესახებ უნდა იცოდეს: რომელია შეცვლილი, რომელი არ არის თვალთვალში და ემთხვევა თუ არა ქეშირებული ინდექსის მონაცემები ჯერ კიდევ დისკზე არსებულს. SSHFS-ის გავლით ამ დაკვირვებიდან თითოეული შეიძლება იყოს ქსელური ოპერაცია. სამუშაოს ერთეული აქ ფაილების რაოდენობაა, არა მეგაბაიტები.

ამიტომ კლონის შემდეგ პირველი status ნელია, და ამიტომ შემდეგები შეიძლება კიდევ უფრო ნელი იყოს აშენების გამონატანით სავსე ხეში. მიუყოლებელი ფაილების სკანირება დადის იმ საქაღალდეებში, რომლებიც შეიძლება არ გაინტერესებდეთ, და ყოველი ნაბიჯი კიდევ ერთი მოთხოვნაა კავშირზე. 40 ms-ის გზაზე რამდენიმე ათასი ჩანაწერის ხე რამდენიმე ათას მოგზაურობად იქცევა. ამ არითმეტიკის დასადასტურებლად პაკეტების დაჭერა არ არის საჭირო.

ჩამოტვირთვის საზომი გეუბნებათ, რომ კავშირი კარგია; ის არაფერს ამბობს იმაზე, დასრულდება თუ არა ათასი პატარა წაკითხვა დღეს შუადღის შემდეგ.

გადაიტანეთ სამუშაო ხე და არა მორგების ღილაკები

ლოკალური კლონი სამუშაო ხეს, ინდექსს და Git-ის ოპერაციებს ერთ მანქანაზე ათავსებს. pull ხილულ ქსელურ ნაბიჯად იქცევა, ნაცვლად იმისა, რომ ყოველი ფაილის შემოწმება ასეთი იყოს.

ეს შეესაბამება ყოველთვის, როცა დეველოპერს შეუძლია საჭირო წყარო ლოკალურად შეინახოს, რაც უმეტეს შემთხვევაში ასეა. ის ასევე ამკვეთრებს commit-სა და გაშვებას შორის საზღვარს, რადგან ლოკალური ფაილის რედაქტირება აღარ ცვლის შემთხვევით მომუშავე დისტანციურ სერვისს; ცვლილება უნდა გაიგზავნოს და განთავსდეს, როგორც ყველაფერი სხვა. ფასი ისაა, რომ კოდი ორ ადგილზე არსებობს, ამიტომ გადაწყვიტეთ, რომელი ასლია ავტორიტეტული და როგორ ბრუნდება სერვერზე გაკეთებული სწრაფი შესწორება საცავში. ეს საუბარი იაფია, ვიდრე status-ის ბრძანება, რომლის გაშვებაც არავის სურს.

თუ სამუშაო სივრცე დისტანციური უნდა დარჩეს, Git იქ გაუშვით

ზოგჯერ სამუშაო სივრცეს გადატანა არ შეიძლება: აშენებას სჭირდება ის გარემო, მონაცემები ძალიან დიდია, ან პოლიტიკა წყაროს ჰოსტზე ინახავს. მაშინ გაუშვით Git და შესაბამისი განვითარების ხელსაწყოები ფაილების გვერდით, დამტკიცებული დისტანციური გარსის ან დისტანციური განვითარების გარემოს მეშვეობით. რედაქტორი შეიძლება დარჩეს ლეპტოპზე, სანამ მისი backend მუშაობს სამუშაო ხის გვერდით.

ძვირადღირებული ოპერაციები მაშინ ლოკალურად ხდება დისტანციურ ჰოსტზე, და ქსელი ატარებს რედაქტორის ტრაფიკს ათასობით stat გამოძახების ნაცვლად. ეს იგივე შესწორებაა, რაც ლოკალური კლონი, გამოხატული განთავსების არჩევანად და არა მიგრაციად.

სინქრონიზაცია მფლობელების მქონე სამუშაო პროცესია და არა ქეში

სინქრონიზებულ სამუშაო სივრცეს შეუძლია შეამციროს განმეორებითი დისტანციური წაკითხვები, მაგრამ ეს არ არის გამჭვირვალე ქეში. მას სჭირდება მფლობელი ყოველი ცვლილებისთვის, წესი კონფლიქტებისთვის და შეთანხმება წარმოქმნილ ფაილებზე, რომლებსაც ორივე მხარე თავისად მიიჩნევს. ამ წესების გარეშე მოწყობა ქმნის უთანხმოებას და არა სიმყუდროვეს.

ორმხრივი სინქრონიზატორი მათ გარეშე ქმნის სხვა პრობლემას, ვიდრე გადაჭრა, ჩვეულებრივ ისეთ გაერთიანებას, რომლის მიკუთვნებაც ვერავის შეუძლია. მოერიდეთ ორი Git პროცესის გაშვებას ერთ საერთო სამუშაო ხეზე, თუ არ გესმით, როგორ კოორდინირდება ისინი.

შემდეგ მორგეთ და SSH გონივრულად შეინარჩუნეთ

როცა მოწყობა სწორია, ორი პარამეტრი ცვლის, რამდენ ფაილზე უნდა იკითხოს Git-მა: status.showUntrackedFiles და core.untrackedCache-ის უკან მდგარი მიუყოლებელი ქეში. არც ერთი არ ცვლის, რა ღირს ყოველი კითხვა 40 ms-ზე; ისინი მხოლოდ კითხვების რაოდენობას ცვლიან. ღილაკი მოუხვიეთ მხოლოდ მაშინ, როცა მოგზაურობები ლოკალურია.

გაზომეთ იმ ბრძანების დრო, რომელიც გაღიზიანებთ, ნაცვლად იმისა, რომ იმსჯელოთ ერთი დიდი ფაილის კოპირების საზომიდან, და მხარდაჭერილი SSH დაშიფვრა მშვიდად დატოვეთ. მოძველებული შიფრი არ ამოკლებს მოგზაურობას; ის ამატებს მეორე პრობლემას, რომელიც პირველზე დიდხანს ცოცხლობს. git status-ის ცნობარი ერთი წაკითხვის ღირსია, რადგან ბრძანება გაცილებით მეტ სამუშაოს ასრულებს, ვიდრე მისი სახელი გვთავაზობს.