Claude Code for performance investigations: a measured workflow

ทำไมงานด้านประสิทธิภาพถึงผิดพลาดเมื่อขาดการวัดผล\n\nบั๊กด้านประสิทธิภาพชวนให้เดา เมื่อคนสังเกตว่าหน้าเว็บรู้สึกช้าหรือ API หมดเวลา การเคลื่อนไหวที่เร็วที่สุดมักเป็นการ "ทำความสะอาด" โค้ด, เพิ่มแคช หรือเขียนลูปใหม่ ปัญหาคือ "รู้สึกช้า" ไม่ใช่เมตริก และ "ดูสะอาดขึ้น" ไม่เท่ากับเร็วขึ้น\n\nถ้าไม่วัด ทีมมักเสียเวลาไปกับการเปลี่ยนแปลงสิ่งที่ไม่ใช่ต้นตอ เส้นทางฮอตอาจอยู่ที่ฐานข้อมูล เครือข่าย หรือการจัดสรรที่ไม่คาดคิดหนึ่งจุด ในขณะที่ทีมขัดโค้ดที่แทบไม่ได้รัน แย่กว่านั้น การเปลี่ยนแปลงที่ดูฉลาดอาจทำให้ประสิทธิภาพแย่ลง: การบันทึกเพิ่มในลูปรัดตัว, แคชที่เพิ่มแรงกดดันหน่วยความจำ, หรือการทำงานขนานที่สร้างการแย่งล็อก\n\nการเดายังเสี่ยงทำให้พฤติกรรมเสีย เมื่อคุณเปลี่ยนโค้ดเพื่อให้เร็วขึ้น อาจเปลี่ยนผลลัพธ์ การจัดการข้อผิดพลาด ลำดับการทำงาน หรือการลองใหม่ หากคุณไม่ตรวจสอบความถูกต้องและความเร็วพร้อมกัน คุณอาจ "ชนะ" เกณฑ์มาตรวัดขณะส่งบั๊กเงียบ ๆ\n\nปฏิบัติต่องานประสิทธิภาพเหมือนการทดลอง ไม่ใช่การโต้วาที วงจรง่ายและทำซ้ำได้:\n\n- เลือกเมตริกหนึ่งตัวที่แทนความเจ็บปวด (latency, throughput, CPU, memory, เวลา DB)\n- จับเส้นฐานภายใต้เงื่อนไขเดียวกัน\n- เปลี่ยนสิ่งเล็ก ๆ หนึ่งอย่าง\n- วัดใหม่และเปรียบเทียบ\n\nหลายชัยชนะมักเล็กน้อย: ตัด p95 ลง 8%, ลดพีคหน่วยความจำ 50 MB, หรือตัดหนึ่งคำสั่งฐานข้อมูล ชัยชนะเหล่านี้ยังมีความหมาย แต่มีค่าเมื่อวัด ยืนยัน และทำซ้ำได้\n\n## เวิร์กโฟลว์: วัด → ตั้งสมมติฐาน → เปลี่ยน → วัดซ้ำ\n\nวิธีนี้ได้ผลดีที่สุดเป็นลูป ไม่ใช่คำขอ "ทำให้เร็วขึ้น" ครั้งเดียว ลูปช่วยให้คุณตรงไปตรงมาเพราะทุกการกระทำผูกกับหลักฐานและตัวเลขที่คุณดูได้\n\nลำดับชัดเจน:\n\n- วัด: เลือกเมตริกหนึ่งและบันทึกเส้นฐาน\n- ตั้งสมมติฐาน: อธิบายสิ่งที่คิดว่าช้าและทำไม\n- เปลี่ยน: ทำการแก้ไขเล็กที่สุดที่ทดสอบสมมติฐาน\n- วัดซ้ำ: รันการวัดเดิมอีกครั้งแล้วเปรียบเทียบ\n\nแต่ละขั้นตอนป้องกันการหลอกตัวเองแบบต่าง ๆ การวัดก่อนหยุดคุณจากการ "แก้" สิ่งที่ไม่ใช่ปัญหาจริง สมมติฐานเป็นลายลักษณ์อักษรหยุดคุณจากการเปลี่ยนหลายอย่างพร้อมกันแล้วเดาว่าอันไหนสำคัญ การเปลี่ยนแปลงเล็ก ๆ ลดความเสี่ยงในการทำให้พฤติกรรมเสียหรือเพิ่มคอขวดใหม่ การวัดซ้ำจับชัยชนะเพลสโบ (เช่นการรันที่เร็วขึ้นเพราะแคชอุ่น) และเปิดเผยการถดถอย\n\n"เสร็จ" ไม่ใช่ความรู้สึก แต่เป็นผลลัพธ์: เมตริกเป้าหมายเคลื่อนไปในทิศทางที่ถูกต้อง และการเปลี่ยนแปลงไม่ก่อให้เกิดการถดถอยที่ชัดเจน (ข้อผิดพลาด, หน่วยความจำสูงขึ้น, p95 แย่ลง, หรือ endpoint ใกล้เคียงช้าลง)\n\nการรู้ว่าเมื่อหยุดเป็นส่วนหนึ่งของเวิร์กโฟลว์ หยุดเมื่อกำไรแผ่วลง เมตริกดีพอสำหรับผู้ใช้ หรือเมื่อไอเดียถัดไปต้องการรีแฟกเตอร์ใหญ่เพื่อผลตอบแทนน้อย งานประสิทธิภาพมีต้นทุนโอกาส; ลูปช่วยให้คุณใช้เวลาในที่ที่คุ้มค่า\n\n## เลือกเมตริกและล็อกเส้นฐาน\n\nถ้าคุณวัดห้าสิ่งพร้อมกัน คุณจะไม่รู้ว่าอะไรดีขึ้น เลือกเมตริกหลักหนึ่งตัวสำหรับการสืบสวนนี้และถือสิ่งอื่นเป็นสัญญาณเสริม สำหรับปัญหาหน้าแสดงผล เมตริกมักเป็น latency สำหรับงานแบตช์อาจเป็น throughput, เวลา CPU, การใช้หน่วยความจำ หรือแม้แต่ต้นทุนคลาวด์ต่อรัน\n\nระบุสถานการณ์ให้ชัดเจน "API ช้า" กว้างเกินไป "POST /checkout กับตะกร้าทั่วไป 3 รายการ" วัดได้ เก็บอินพุตให้คงที่เพื่อให้ตัวเลขมีความหมาย\n\nจดเส้นฐานและรายละเอียดสภาพแวดล้อมก่อนแตะโค้ด: ขนาดชุดข้อมูล, ประเภทเครื่อง, โหมดบิลด์, ฟีเจอร์แฟล็ก, ความขนาน, และการวอร์มอัพ เส้นฐานนี้คือสมอของคุณ หากไม่มีมัน ทุกการเปลี่ยนแปลงจะดูเหมือนความก้าวหน้า\n\nสำหรับ latency ให้พึ่งพาเปอร์เซ็นไทล์ ไม่ใช่ค่าเฉลี่ย p50 แสดงประสบการณ์ทั่วไป ขณะที่ p95 และ p99 เปิดเผยหางที่ผู้ใช้บ่น การเปลี่ยนแปลงที่ปรับปรุง p50 แต่ทำให้ p99 แย่ลงยังอาจทำให้รู้สึกช้าลง\n\nตัดสินล่วงหน้าว่า "มีความหมาย" คืออะไร เพื่อไม่ฉลองจากเสียงรบกวน:\n\n- Latency: ปรับปรุง p95 อย่างน้อย 10% (หรือเกณฑ์คงที่เช่น 50 ms)