Bumagal ang git status sa SSHFS sa VPN: ilipat ang trabaho

Kopyahin ang 200 MB na file at lumilipad ito. Patakbuhin ang git status sa parehong direktoryo at sapat ang tagal ng paghihintay upang lumipat ng atensyon. Ang dalawang obserbasyon ay hindi magkasalungat, dahil sinusukat ng bulk transfer ang throughput samantalang sinusukat ng Git kung ilang maliliit na tanong sa filesystem ang maitatanong nito bawat segundo, at ginagawang pabalik-balik ng naka-mount na remote tree ang bawat tanong. Hindi maaayos ng pag-tune sa VPN ang maling hugis na workload.

Bakit mali ang status bilang sukatan

Kailangang malaman ng Git ang tungkol sa maraming file: alin ang binago, alin ang hindi sinusubaybayan at kung tumutugma pa ang naka-cache na index data sa nasa disk. Sa SSHFS ang bawat isa sa mga obserbasyong iyon ay maaaring operasyon sa network. Ang yunit ng trabaho dito ay bilang ng file, hindi megabytes.

Kaya mabagal ang unang status pagkatapos ng clone, at kaya mas mabagal pa ang mga susunod sa punong puno ng build output. Ang pag-scan ng hindi sinusubaybayan ay dumadaan sa mga direktoryo na maaaring wala kang pakialam, at bawat hakbang ay isa pang kahilingan sa link. Sa 40 ms na landas, ang punong may ilang libong entry ay nagiging ilang libong pabalik-balik. Hindi kailangan ng packet capture para kumpirmahin ang aritmetikang iyon.

Sinasabi ng download benchmark na maayos ang link; wala itong sinasabi tungkol sa kung matatapos ngayong hapon ang isang libong maliliit na pagbasa.

Ilipat ang working tree, hindi ang tuning knobs

Inilalagay ng lokal na clone ang working tree, index at mga operasyon ng Git sa isang makina. Ang pull ay nagiging nakikitang hakbang sa network sa halip na bawat file check.

Angkop ito tuwing kayang itago ng developer ang kailangang source nang lokal, na kadalasan ay ganoon. Pinapatalas din nito ang hangganan ng commit at deployment, dahil ang pag-edit ng lokal na file ay hindi na aksidenteng nagbabago ng tumatakbong remote service; kailangang i-push at i-deploy ang pagbabago tulad ng iba pa. Ang kabayaran ay may kopya ang code sa dalawang lugar, kaya magpasya kung aling kopya ang awtoritatibo at paano bumabalik sa repository ang hotfix sa server. Mas mura ang usapang iyon kaysa sa status command na walang gustong patakbuhin.

Kung kailangang manatiling remote ang workspace, patakbuhin ang Git doon

Minsan hindi mailipat ang workspace: kailangan ng build ang environment na iyon, masyadong malaki ang data, o pinapanatili ng patakaran ang source sa host. Kaya patakbuhin ang Git at ang kaugnay na development tools sa tabi ng mga file, sa pamamagitan ng aprubadong remote shell o remote-development environment. Maiiwan ang editor sa laptop habang nagtatrabaho ang backend nito sa tabi ng working tree.

Ang magastos na operasyon ay nangyayari nga nang lokal sa remote host, at ang network ay nagdadala ng trapiko ng editor sa halip na libu-libong stat call. Ito ang parehong lunas ng lokal na clone, na inihayag bilang pagpipilian sa deployment at hindi migration.

Ang sync ay workflow na may mga may-ari, hindi cache

Ang naka-sync na workspace ay makakabawas ng paulit-ulit na remote read, ngunit hindi ito transparent na cache. Kailangan nito ng may-ari para sa bawat pagbabago, patakaran para sa mga salungatan, at kasunduan sa mga generated file na inaakala ng dalawang panig na kanila. Kung wala ang mga patakarang iyon, ang kaayusan ay lumilikha ng hindi pagkakasundo sa halip na kaginhawahan.

Ang two-way synchronizer na wala ang mga ito ay gumagawa ng problemang iba sa nalutas nito, kadalasan isang merge na walang makapag-uugnay. Iwasang patakbuhin ang dalawang Git process sa isang shared working tree maliban kung nauunawaan mo kung paano sila nag-uugnay.

Pagkatapos ay i-tune, at panatilihing matino ang SSH

Kapag tama na ang kaayusan, may dalawang setting na nagbabago kung ilang file ang tatanungin ng Git: status.showUntrackedFiles at ang cache ng hindi sinusubaybayan sa likod ng core.untrackedCache. Wala sa kanila ang nagbabago sa gastos ng bawat tanong sa 40 ms; binabago lang nila kung ilang tanong. Iikot ang knob kapag lokal na ang pabalik-balik.

Sukatin ang oras ng command na nakakainis sa iyo sa halip na mangatwiran mula sa benchmark na kumokopya ng isang malaking file, at hayaang manatili ang suportadong SSH encryption. Ang lipas na cipher ay hindi nagpapaikli ng pabalik-balik; nagdadagdag ito ng pangalawang problema na mas matagal kaysa sa una. Ang reference ng git status ay sulit basahin nang isang beses, dahil mas marami ang ginagawa ng command kaysa sa ipinahihiwatig ng pangalan nito.