ฝันร้ายของ Admin หลายคนเกิดมาจากคำว่า ‘ช้า’ ซึ่งเมื่อเกิดในระดับแอปพลิเคชันแล้วต้องไล่ปัญหายาวกันทีเดียวว่าเกิดที่ใคร โดยวันนี้เราขอสรุปเกร็ดเล็กน้อย 10 ข้อจาก NoJitter ในการตรวจสอบแอปพลิเคชันช้ามาให้ได้อ่านกันหวังว่าจะเป็นประโยชน์กับทุกท่านครับ
ผู้เขียนได้ทำการแบ่งปัญหาออกเป็น 4 กลุ่มซึ่งเกร็ดความรู้ 10 ข้อในวันนี้จะครอบคลุมแค่ครึ่งแรก โดยกลุ่มทั้งหมดมีดังนี้
-
Client-side Process ปัญหาที่เกิดขึ้นในฝั่งเครื่อง Client เอง
-
Network Transport ปัญหาที่เกิดขึ้นในระดับเครือข่ายซึ่งกระทบกับแอปพลิเคชัน
-
Server-side ปัญหาจากระดับโครงสร้างของแอปพลิเคชันที่เขียนขึ้นมาเอง
-
Multifuction interaction มีการสื่อสารเชื่อมต่อกันระหว่างหลายส่วนทำให้เกิดการลดทอนประสิทธิภาพ
Client-Side Processing
1.Admin ควรหาเครื่องมือมาช่วยดูประสิทธิภาพของเครื่องในฝั่ง Client เพื่อดูว่าแอปพลิเคชันนั้นกินทรัพยากรในเครื่องขนาดไหน รวมถึงหาเครื่องมือมาจับปริมาณการรับข้อมูลจาก Server ด้วยเพราะบางแอปพลิเคชันมีลักษณะกระจายโหลดมาให้เครื่องปลายทางช่วยประมวลผลซึ่งอาจเกิดจากหลายปัจจัย เช่น ขนาดของข้อมูล ขนาดของโค้ด และความซับซ้อนจากอัลกอริทึมของผู้พัฒนาโปรแกรม
2.เครื่อง Client เก่า ตัวอย่างเช่น ดิสก์ที่มีการใช้งานเกือบเต็มจะมีประสิทธิภาพด้อยลงอย่างเห็นได้ชัดเพราะระบบเสียเวลาไปกับการค้นหาพื้นที่ว่างสำหรับเขียนข้อมูล หรือ เครื่อง Client ของ VDI เก่าไม่รองรับกับไฟล์วีดีโอสมัยใหม่ที่ละเอียดขึ้น แม้กระทั้งวีดีโอที่มีการเคลื่อนไหวของภาพเยอะก็อาจทำให้แสดงผลได้ช้าจนผู้ใช้บ่นกันได้
3.ตรวจดูให้ดีว่ามีงานอื่นแย่งทรัพยากรเราหรือเปล่าโดยเฉพาะขั้นตอนสแกนไวรัสรายวัน การ Backup แม้กระทั้งการดู Streaming Video ก็อาจส่งผลกระทบต่อแอปพลิเคชันที่เราต้องการใช้ทำงาน
Network Transport
4.มีแพ็กเก็ตสูญหายจำนวนมากระหว่างการส่งในเครือข่ายซึ่งจะไปสัมพันธ์กับลักษณะของแอปพลิเคชันด้วยว่าเป็น TCP หรือ UDP
5.หลายคนมองข้ามปัญหาเรื่องของ Latency ซึ่งในบางแอปพลิเคชันไม่สามารถทนต่อการปัญหาประเภทนี้ได้ เช่น แอปพลิเคชันที่ต้องส่ง Request กันไปมาจำนวนมากระหว่าง Client และ Server หรือต้องมีการคุยกันระหว่างกลุ่มของ Server เอง โดยเมื่อรวมกับเวลาประมวลผลบนเครื่องอาจทำให้แอปพลิเคชันอาจเกิดปัญหาช้าได้
6.ค่า Jitter ก็มีผลต่อแอปพลิเคชันประเภท Real-time อย่างเสียงหรือวีดีโอด้วย เพราะแอปพลิเคชันเหล่านี้จำเป็นต้องได้รับแพ็กเก็ตในลำดับที่กำหนดไม่งั้นคุณภาพแย่ลง โดยสาเหตุที่ส่งผลให้ Jitter มีค่าสูงมีหลายประการ ตัวอย่างเช่น Bufferbloat หรือการที่อุปกรณ์เครือข่ายมีขนาด Buffer ใหญ่เกินไปทำให้กว่าจะจัดการคิวช้า อย่างไรก็ตามการทำ QoS ให้แอปพลิเคชันก็เป็นการแก้ปัญหาได้ทางหนึ่งซึ่ง Admin ต้องศึกษาให้ดี
7.การเปลี่ยนแปลงของเส้นทางเครือข่ายก็มีผลอย่างมาก เช่น กรณีของ Stateful Firewall สองตัว (redundant) ที่ไม่ได้ตั้งให้มีการแชร์ State กันทำให้ตัวฝั่ง Redundant บล็อก Flow ที่เปลี่ยนเส้นทางมาใหม่ทำให้ Transaction ของแอปพลิเคชันไม่สมบูรณ์จึงเกิดการส่งใหม่กลายเป็นปัญหาขึ้นมา
8.การตั้งค่า Wi-Fi ให้เข้ากันได้กับอุปกรณ์ฝั่ง Client รุ่นเก่าที่ใช้งานความเร็วต่ำก็มีผล ดังนั้นควรจะแยกโครงสร้างของ Wireless สำหรับอุปกรณ์แบบเก่าและแบบใหม่กันไปเลยจะดีกว่า
9.ประสิทธิภาพของ Wi-Fi ไม่ครอบคลุมหรือดีแค่บางจุด ตรงนี้ในตอนวางแผนติดตั้งจะต้องทำ Site Survey จุดสำคัญและตรวจสอบสิ่งกีดขวางต่างๆ เช่น วัสดุของกำแพงห้องที่สัญญาณจะต้องกระจายผ่าน โดยแนะนำให้ใช้รัศมีของสัญญาณให้เล็กหน่อยแต่มีหลายช่องสัญญาณในย่านความถี่ 5GHz ก็ช่วยได้ นอกจากนี้สามารถใช้ฟีเจอร์ Location Service เพื่อดูตำแหน่งของผู้ใช้งานที่แจ้งว่าแอปพลิเคชันช้า
10.Bandwidth ของเครือข่ายไม่พอคือแหล่งรวมปัญหาที่จะไหลเข้ามาทั้งเรื่อง ไม่สามารถคาดเดา Latency, ปัญหาการสูญหายของข้อมูล และเกิดความคับคั่งของข้อมูลจนส่งผลกับทุกแอปพลิเคชันไปด้วย ดังนั้น Admin ควรจะทำการสำรวจดูว่าอินเทอร์เฟสไหนเกิดการ Drop แพ็กเก็ตมากที่สุดโดยอาจจะจัดทำเป็น 20 อันดับแรกขึ้นมาเป็นข้อมูลอ้างอิงเพื่อเป็นไอเดียในการแก้ปัญหาต่อไป
ที่มา : https://www.nojitter.com/monitoring-management/10-tips-diagnosing-slow-applications/page/0/1