git status ช้าบน SSHFS ผ่าน VPN: ย้ายงาน

คัดลอกไฟล์ 200 MB แล้วมันบินได้ รัน git status ในไดเรกทอรีเดียวกันแล้วการรอจะนานพอที่จะหันไปทำอย่างอื่น ข้อสังเกตสองข้อนี้ไม่ขัดแย้งกัน เพราะการถ่ายโอนจำนวนมากวัดปริมาณงานที่ส่งได้ ส่วน Git วัดว่าถามคำถามเล็ก ๆ กับระบบไฟล์ได้กี่ครั้งต่อวินาที และ ทรีระยะไกลที่เมานต์ไว้เปลี่ยนทุกคำถามให้เป็นการไปกลับ การปรับแต่ง VPN ไม่ได้แก้ภาระงานที่ออกแบบผิดรูป

ทำไม status จึงเป็นมาตรวัดที่ผิด

Git ต้องรู้เรื่องไฟล์จำนวนมาก ทั้งไฟล์ที่แก้ไข ไฟล์ที่ยังไม่ถูกติดตาม และข้อมูล index ที่แคชไว้ยังตรงกับสิ่งที่อยู่บนดิสก์หรือไม่ ผ่าน SSHFS การสังเกตแต่ละอย่างเหล่านี้อาจเป็นการทำงานบนเครือข่าย หน่วยของงานตรงนี้คือจำนวนไฟล์ ไม่ใช่เมกะไบต์

นั่นคือเหตุผลที่ status ครั้งแรกหลัง clone ช้า และเหตุผลที่ครั้งต่อไปอาจช้ากว่าในทรีที่เต็มไปด้วยผลลัพธ์การ build การสแกนไฟล์ที่ยังไม่ถูกติดตามเดินผ่านไดเรกทอรีที่คุณอาจไม่สนใจ และทุกย่างก้าวคือคำขออีกครั้งผ่านลิงก์ บนเส้นทาง 40 ms ทรีที่มีไม่กี่พันรายการจะกลายเป็นหลายพันครั้งของการไปกลับ ไม่ต้องดักจับแพ็กเก็ตเพื่อยืนยันเลขคณิตนี้

มาตรวัดการดาวน์โหลดบอกว่าลิงก์ดี แต่ไม่บอกอะไรเลยว่าการอ่านเล็ก ๆ พันครั้งจะเสร็จในบ่ายวันนี้หรือไม่

ย้ายทรีงาน ไม่ใช่ปุ่มปรับแต่ง

clone ในเครื่องวางทรีงาน index และการทำงานของ Git ไว้บนเครื่องเดียวกัน pull จึงกลายเป็นขั้นตอนเครือข่ายที่มองเห็นได้ แทนที่จะเป็นการตรวจไฟล์ทุกครั้ง

วิธีนี้เหมาะทุกครั้งที่นักพัฒนาสามารถเก็บซอร์สที่จำเป็นไว้ในเครื่อง ซึ่งส่วนใหญ่เป็นเช่นนั้น นอกจากนี้ยังทำให้เส้นแบ่งระหว่าง commit และการ deploy คมชัดขึ้น เพราะการแก้ไฟล์ในเครื่องไม่เปลี่ยนบริการระยะไกลที่กำลังทำงานโดยไม่ตั้งใจอีกต่อไป การเปลี่ยนแปลงต้องถูก push และ deploy เหมือนอย่างอื่น ราคาที่ต้องจ่ายคือโค้ดมีอยู่สองที่ จึงต้องตัดสินว่าสำเนาใดเป็นหลัก และ hotfix บนเซิร์ฟเวอร์กลับเข้าคลังอย่างไร บทสนทนานั้นถูกกว่าคำสั่ง status ที่ไม่มีใครอยากรัน

ถ้าพื้นที่ทำงานต้องอยู่ระยะไกล ให้รัน Git ที่นั่น

บางครั้งพื้นที่ทำงานย้ายไม่ได้ การ build ต้องใช้สภาพแวดล้อมนั้น ข้อมูลใหญ่เกินไป หรือนโยบายเก็บซอร์สไว้บนโฮสต์ จึงควรรัน Git และเครื่องมือพัฒนาที่เกี่ยวข้องข้างไฟล์ ผ่านเชลล์ระยะไกลที่ได้รับอนุมัติหรือสภาพแวดล้อมพัฒนาระยะไกล เอดิเตอร์อยู่บนแล็ปท็อปได้ ในขณะที่แบ็กเอนด์ทำงานข้างทรีงาน

การทำงานที่แพงจึงเกิดขึ้นในเครื่องบนโฮสต์ระยะไกล และเครือข่ายรับส่งทราฟฟิกของเอดิเตอร์แทนการเรียก stat หลายพันครั้ง นี่คือการแก้แบบเดียวกับ clone ในเครื่อง แต่พูดในฐานะทางเลือกการ deploy ไม่ใช่การย้ายระบบ

การซิงก์คือเวิร์กโฟลว์ที่มีเจ้าของ ไม่ใช่แคช

พื้นที่ทำงานที่ซิงก์กันสามารถลดการอ่านระยะไกลซ้ำ ๆ ได้ แต่มันไม่ใช่แคชที่โปร่งใส ต้องมีเจ้าของสำหรับทุกการเปลี่ยนแปลง กฎสำหรับความขัดแย้ง และข้อตกลงเรื่องไฟล์ที่สร้างขึ้นซึ่งทั้งสองฝ่ายคิดว่าเป็นของตน หากไม่มีกฎเหล่านั้น การจัดวางจะสร้างความขัดแย้งแทนความสะดวก

ตัวซิงก์สองทางที่ไม่มีกฎเหล่านั้นจะสร้างปัญหาที่ต่างจากที่มันแก้ มักเป็นการ merge ที่ไม่มีใครระบุที่มาได้ หลีกเลี่ยงการรันโปรเซส Git สองตัวบนทรีงานที่ใช้ร่วมกัน เว้นแต่คุณเข้าใจว่าพวกมันประสานกันอย่างไร

จากนั้นปรับแต่ง และรักษา SSH ให้สมเหตุสมผล

เมื่อการจัดวางถูกต้องแล้ว การตั้งค่าสองอย่างจะเปลี่ยนจำนวนไฟล์ที่ Git ต้องถาม คือ status.showUntrackedFiles และแคชไฟล์ที่ยังไม่ถูกติดตามหลัง core.untrackedCache ไม่มีตัวใดเปลี่ยนต้นทุนของแต่ละคำถามตลอด 40 ms เปลี่ยนเพียงจำนวนคำถาม ปรับปุ่มเมื่อการไปกลับเป็นเรื่องในเครื่องแล้วเท่านั้น

วัดเวลาของคำสั่งที่กวนใจคุณ แทนที่จะให้เหตุผลจากมาตรวัดที่คัดลอกไฟล์ใหญ่หนึ่งไฟล์ และปล่อยการเข้ารหัส SSH ที่รองรับไว้ตามเดิม รหัสลับที่ล้าสมัยไม่ได้ย่นการไปกลับให้สั้นลง มันเพิ่มปัญหาที่สองซึ่งอยู่ได้นานกว่าปัญหาแรก เอกสารอ้างอิง git status คุ้มค่าที่จะอ่านสักครั้ง เพราะคำสั่งนี้ทำงานมากกว่าที่ชื่อบอกไว้มาก