การวิเคราะห์ผลการปฏิบัติงานของ Redis

ในงวดที่แล้ว ฉันได้กล่าวถึงหัวข้อและแนวทางในการป้องกันไม่ให้อินสแตนซ์ Redis ของคุณทำงานช้า ถึงเวลาสำรวจวิธีการ การวัด ประสิทธิภาพ

วัดอะไร

สำหรับงวดนี้ เรากำลังดูเวลาแฝงของคำสั่งและส่วนประกอบต่างๆ ทำไม เนื่องจากจำนวนคำสั่งที่คุณสามารถส่งผ่านเซิร์ฟเวอร์/ไลบรารี Redis เป็นผลมาจากความเร็วของแต่ละคำสั่ง

รวดเร็วและง่ายดาย:CLI

วิธีแรกในการตรวจสอบเวลาแฝงของคำสั่งคือการใช้ไคลเอ็นต์บรรทัดคำสั่ง redis-cli . รวดเร็วและให้จุดตรวจทันทีเพื่อเริ่มต้น ตัวอย่างที่นี่จะใช้ localhost เพื่อความง่าย แต่ในการตั้งค่าของคุณ คุณควรใช้ -h <host> ตัวเลือกและถ้าจำเป็น -a <auth> และ -p <port> .

เวลาแฝงพื้นฐาน

หากต้องการรับผลลัพธ์เวลาแฝงพื้นฐาน ให้เรียกใช้ redis-cli –latency ซึ่งจะแสดงผลชุดตัวเลขที่ระบุค่าต่ำสุด สูงสุด เฉลี่ย และจำนวนการวนซ้ำ การทำซ้ำเหล่านี้ประกอบด้วยการรันคำสั่ง Redis PING กับการเชื่อมต่อแบบเปิด ดังนั้นจึงไม่รวมเวลาในการเชื่อมต่อกับเซิร์ฟเวอร์ หากโค้ดของคุณเชื่อมต่อกับทุกคำสั่ง คุณจะเห็นประสิทธิภาพที่แย่กว่าที่คำสั่งนี้จะระบุมาก

คำสั่งนี้จะรันจนกว่าคุณจะฆ่ามัน—ทำได้ง่ายๆ ผ่าน CTRL-C ตัวเลขแฝงอยู่ในหน่วยมิลลิวินาที ดังนั้นผลลัพธ์ของ:

min: 0, max: 1, avg: 0.11 (11369 samples)

หมายถึงเวลาแฝงต่ำสุดน้อยกว่า 1 มิลลิวินาที สูงสุดคือ 1 มิลลิวินาที โดยมีเวลาแฝงเฉลี่ยต่อ PING ที่ 0.11 มิลลิวินาที ใช่ นี่คือการเชื่อมต่อ localhost ตัวเลขเหล่านี้เป็นผลลัพธ์ที่คำนวณจาก 11,369 “ตัวอย่าง” หรือคำสั่ง PING

หรือคุณสามารถใช้ –latency-history แทน ตัวเลือกนี้ช่วยให้คุณแยกออกเป็นชิ้นชั่วขณะได้ การรัน redis-cli –latency-history จะใช้หน้าต่างเริ่มต้น 15 วินาที ผลลัพธ์จะออกมาประมาณนี้:

min: 0, max: 1, avg: 0.11 (1475 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.10 (1474 samples) -- 15.01 seconds range

เช่นเดียวกับ –latency คำสั่งนี้จะรันจนกว่าคุณจะฆ่ามัน หากคุณต้องการวิ่งด้วยช่วงเวลาอื่นคุณสามารถผ่าน -i ได้ ตัวอย่างเช่น:

redis-cli --latency-history  -i 10
min: 0, max: 1, avg: 0.11 (984 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range

เนื่องจากการดำเนินการเหล่านี้เพียงใช้คำสั่ง PING จึงควรใช้ได้กับ Redis เวอร์ชันใดก็ได้

เวลาแฝงภายใน

เมื่อมองแวบแรก ชื่ออาจทำให้คุณเชื่อว่าโหมดเวลาแฝงภายในกำลังวัดเวลาแฝงที่แท้จริงของเซิร์ฟเวอร์ มันไม่ใช่ หากคุณดูที่แหล่งที่มาของ redis-cli บน GitHub คุณจะพบว่าไม่มีการพูดคุยกับเซิร์ฟเวอร์:

start = ustime();
compute_something_fast();
end = ustime();
latency = end-start;

ตามความคิดเห็นของแหล่งที่มาในโหมดแฝงที่แท้จริง:

วัดเวลาแฝงสูงสุดของกระบวนการที่ทำงานอยู่ซึ่งไม่ได้เป็นผลมาจาก syscalls โดยทั่วไป ซอฟต์แวร์นี้ควรให้คำแนะนำเกี่ยวกับระยะเวลาที่เคอร์เนลออกจากกระบวนการโดยไม่มีโอกาสทำงาน

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

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

การใช้คอมมิสซาร์

Commissar เป็นชุดเครื่องมือขนาดเล็กที่ฉันกำลังทำงานเพื่อติดตามและทดสอบเวลาแฝงของ Redis และประสิทธิภาพโดยรวม คำเตือน:อยู่ในช่วงเริ่มต้นของการพัฒนาและมีแนวโน้มว่าจะมีการเปลี่ยนแปลงมาก ด้วยเหตุนี้ ให้ใช้เฉพาะเมื่อคุณรู้สึกสบายใจกับการใช้ซอฟต์แวร์คุณภาพที่ไม่ใช่การผลิตเท่านั้น ผู้บังคับการตำรวจอยู่ใน The Github Commissar Repository

เราจะดูเครื่องมือ/ไดเรกทอรีเวลาในการตอบสนองโดยเฉพาะสำหรับบทความนี้

เครื่องมือนี้ ซึ่งกำหนดค่าผ่านตัวแปรสภาพแวดล้อม จะเชื่อมต่อกับอินสแตนซ์ Redis ที่กำหนดและเรียกใช้กลไก "เวลาที่คำสั่ง PING" เหมือนกับที่ redis-cli ทำ ฉันทำสิ่งนี้เพื่อรักษาความเท่าเทียมกันของการทดสอบ ความแตกต่างในด้านความสามารถในการส่งออกข้อมูลเพิ่มเติมและ (ปัจจุบัน) เก็บไว้ใน MongoDB พร้อมร้านค้าเพิ่มเติมที่จะมา

เวลาในการตอบสนองอาจมีลักษณะเช่นนี้ แม้ว่าผลลัพธ์จะเปลี่ยนไปตั้งแต่เขียนบทความนี้:

./latency 
Connected to <host:ip>

100000 iterations over 53698us, average 536us/operation

Percentile breakout:
====================
99.00%: 3,876.99us
95.00%: 640.00us
90.00%: 514.00us
75.00%: 452.00us
50.00%: 414.00us

Min: 243us
Max: 44,686us
Mean: 536.98us
Jitter: 764.37us

สังเกตว่าหน่วยชั่วขณะคือ 'เรา' (เช่น ไมโครวินาที) ในการรันครั้งนี้ นอกจากนี้ คุณจะเห็นว่ามันจะทำให้คุณมีการแบ่งเปอร์เซ็นต์ไทล์ วิธีนี้ช่วยให้คุณได้ภาพที่ดีขึ้นว่าเวลาในการตอบสนองเป็นอย่างไรเมื่อเทียบกับค่าต่ำสุด/สูงสุด/เฉลี่ย ในบริบทนี้ 'Jitter' คือค่าเบี่ยงเบนมาตรฐานของกลุ่มตัวอย่าง

ผลลัพธ์นี้บอกเราว่าโดยรวมแล้วเราดูดีมาก ตัวอย่างนี้ใช้ผ่านเครือข่ายส่วนตัว เราสามารถเห็นจุดสูงสุดที่สูงกว่าค่าเฉลี่ยมาก แต่ 95% ของการวนซ้ำมาที่หรือต่ำกว่า 640 ไมโครวินาที สิ่งนี้บอกอะไรเราบ้าง

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

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

ตัวอย่างเช่น ในกรณีนี้ คุณอาจต้องการตรวจสอบเอาต์พุตข้อมูล redis โดยดูที่ส่วน Commandstats โดยเฉพาะ:

redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68

ที่นี่เราจะเห็นว่าเวลาเฉลี่ยในการดำเนินการ PING บนเซิร์ฟเวอร์คือ 0.68 ไมโครวินาที เห็นได้ชัดว่าคำสั่ง ping นั้นไม่น่าจะเป็นผู้ร้าย อย่างไรก็ตาม อาจมีคำสั่งอื่นๆ ที่ดำเนินการในระหว่างการทดสอบซึ่งสนับสนุนกระบวนการ Redis ทำให้เกิดความล่าช้า

การเพิ่มล่าสุดของเครื่องมือเวลาในการตอบสนองคือความสามารถในการเรียกใช้การทดสอบเวลาในการตอบสนองพร้อมกัน ด้วยการตั้งค่าตัวแปรสภาพแวดล้อมใน LATENCY_CLIENTCOUNT คุณสามารถเรียกใช้หลายการเชื่อมต่อไปยังเซิร์ฟเวอร์ Redis ของคุณและดูว่าการทำงานพร้อมกันส่งผลต่อผลลัพธ์เวลาแฝงของคุณมากน้อยเพียงใด ตัวอย่างเช่น คุณสามารถเห็นความแตกต่างที่คำสั่ง Redis PING ธรรมดาเห็นเมื่อคุณมี 10 ไคลเอนต์เทียบกับ 100 หรือแม้แต่ 1,000 ไคลเอนต์พร้อมกัน สิ่งนี้มีประโยชน์ในการดูความแตกต่างที่คุณอาจประสบระหว่างการพัฒนา/การจัดเตรียมและการผลิต

การทดสอบจากคอนเทนเนอร์

ต้องการเรียกใช้การทดสอบจากคอนเทนเนอร์ Docker หรือไม่ ตอนนี้ฉันส่งคอนเทนเนอร์ Docker ที่สร้างขึ้นซึ่งมีเพียงเครื่องมือ golatency ลงในรีจิสทรี Docker สาธารณะ หากคุณใช้นักเทียบท่าดึง therealbill/golatency คุณจะได้รูปภาพที่พร้อมใช้งานในไม่กี่วินาที (ปัจจุบันมีน้ำหนักน้อยกว่า 4MB)

เพียงเรียกนักเทียบท่าที่รันด้วยตัวแปรสภาพแวดล้อมเพื่อเชื่อมต่อและกำหนดค่าตามที่ ReadMe ระบุ จากนั้นดึงเอาต์พุตจาก stdout หรือหากทำงานเป็น daemon ผ่านบันทึกของนักเทียบท่า และคุณไม่จำเป็นต้องสร้างอะไรเลย เมื่อใดก็ตามที่ฉันทำการเปลี่ยนแปลงที่สำคัญกับเครื่องมือ Docker repo จะได้รับการอัปเดตด้วยรูปภาพใหม่ อีกทางหนึ่ง มี Dockerfile ใน repo ที่ให้คุณปรับแต่งได้ตามต้องการ

ความคิดสุดท้าย

การวิเคราะห์ประสิทธิภาพของคุณด้วย Redis อาจเป็นเรื่องยุ่งยาก โชคดีที่มีความเข้าใจเกี่ยวกับเวลาแฝงและปริมาณงานและผลกระทบต่อแอปพลิเคชันของคุณอย่างไร คุณสามารถมุ่งเน้นที่การวิเคราะห์การใช้ Redis ของแอปพลิเคชันของคุณมากกว่าตัว Redis เอง คุณจะปรับปรุงการใช้งานและทำความเข้าใจวิธีที่ดีที่สุดในการใช้ Redis โดยคำนึงถึงวลีของ Zen of Redis "กุญแจสู่ประสิทธิภาพไม่ใช่การทำให้ Redis ทำงานช้าลง" ในขณะเดียวกันก็สร้างแอปพลิเคชันที่ชาญฉลาดและมีประสิทธิภาพมากขึ้นด้วยการแยกปัญหาเครือข่ายและทางเลือกโครงสร้างข้อมูล ส่งผลให้ประสิทธิภาพดีขึ้น