การทดสอบประสิทธิภาพแบบครอบคลุมที่เปรียบเทียบระบบ cache และฐานข้อมูลยอดนิยมได้จุดประกายการอพยพในชุมชนนักพัฒนาอย่างมาก โดยเฉพาะอย่างยิ่งเรื่องการเลือกใช้การแสดงผลข้อมูลและความแตกต่างด้านประสิทธิภาพที่ไม่คาดคิดระหว่างเทคโนโลยีที่คล้ายคลึงกัน
มาตราส่วนลอการิทึมปิดบังความแตกต่างด้านประสิทธิภาพที่แท้จริง
ผลการทดสอบประสิทธิภาพแม้จะมีขอบเขตที่ครอบคลุม แต่ก็ถูกวิพากษ์วิจารณ์เรื่องการใช้มาตราส่วนลอการิทึมในกราฟประสิทธิภาพ การเลือกใช้การแสดงผลแบบนี้ทำให้ผู้อ่านเข้าใจขนาดที่แท้จริงของความแตกต่างด้านประสิทธิภาพระหว่างระบบต่างๆ ได้ยาก สิ่งที่ดูเหมือนเป็นข้อได้เปรียบเพียงเล็กน้อยในแผนภูมิลอการิทึมนั้น จริงๆ แล้วแสดงถึงช่องว่างด้านประสิทธิภาพที่สำคัญ โดย Memcached มีประสิทธิภาพเร็วกว่า Redis ถึงสามเท่าในบางสถานการณ์ แม้ว่าจะดูดีกว่าเพียงเล็กน้อยในกราฟก็ตาม
สมาชิกในชุมชนหลายคนได้เรียกร้องให้นำเสนอข้อมูลใหม่โดยใช้มาตราส่วนเชิงเส้นเพื่อให้ภาพที่ชัดเจนยิ่งขึ้นเกี่ยวกับความแตกต่างด้านประสิทธิภาพในโลกแห่งความเป็นจริง ข้อเสนอแนะนี้เน้นย้ำถึงความสำคัญของการแสดงผลข้อมูลที่เหมาะสมเมื่อนำเสนอการทดสอบประสิทธิภาพทางเทคนิคต่อชุมชน
ผลการวัดประสิทธิภาพที่สำคัญ:
- Memcached เทียบกับ Redis : ประสิทธิภาพของ Memcached เหนือกว่าถึง 3 เท่า (ถูกบดบังด้วยการปรับขนาดแบบลอการิทึม)
- Valkey เทียบกับ Redis : ประสิทธิภาพที่เหนือกว่าอย่างสม่ำเสมอเนื่องจากสถาปัตยกรรมแบบ multithreaded
- Garnet : ประสิทธิภาพ pipeline ที่ยอดเยี่ยมแม้จะใช้การพัฒนาด้วย C
- การปรับขนาด Thread : ประสิทธิภาพคงที่ประมาณ 6-8 threads ในระบบส่วนใหญ่
- ผลกระทบของ Pipeline : การปรับปรุงประสิทธิภาพอย่างมีนัยสำคัญด้วยค่า pipeline ที่สูงขึ้น (1, 10, 100, 1000)
Valkey โผล่มาเป็นทางเลือกที่แข็งแกร่งของ Redis
หนึ่งในผลการค้นพบที่น่าสังเกตที่สุดจากการทดสอบประสิทธิภาพคือ Valkey มีประสิทธิภาพเหนือกว่า Redis อย่างสม่ำเสมอในสถานการณ์การทดสอบต่างๆ ข้อได้เปรียบด้านประสิทธิภาพนี้ดูเหมือนจะเกิดจากสถาปัตยกรรมแบบ multithreaded ของ Valkey ซึ่งตรงข้ามกับการออกแบบแบบ single-threaded ของ Redis ผลลัพธ์นี้ได้สร้างความกระตือรือร้นในหมู่นักพัฒนาที่มองว่านี่เป็นการยืนยันสำหรับ community-driven fork ที่เกิดขึ้นหลังจากการเปลี่ยนแปลงใบอนุญาตของ Redis
ช่องว่างด้านประสิทธิภาพระหว่าง Valkey และ Redis ทำให้ผู้สังเกตการณ์บางคนประหลาดใจที่คาดว่าจะมีความแตกต่างเพียงเล็กน้อยระหว่างสองระบบนี้ อย่างไรก็ตาม การรวมกันของการเพิ่มทุน ความสนใจจากนักพัฒนา และการปรับปรุงสถาปัตยกรรม ได้ทำให้ Valkey ก้าวล้ำหน้าบรรพบุรุษของมันในการทดสอบมาตรฐานเหล่านี้
ระบบที่ทำการทดสอบ:
- Memcache: ระบบจัดเก็บข้อมูลแบบ key-value ในหน่วยความจำ (1 ล้าน keys บน /dev/shm)
- Redis: ระบบจัดเก็บข้อมูลในหน่วยความจำ (1 ล้าน keys บน /dev/shm)
- Valkey: ตัวแยกสาขาของ Redis ที่มีสถาปัตยกรรมแบบ multithreaded
- Garnet: ระบบแคชที่เข้ากันได้กับ Redis ของ Microsoft ที่เขียนด้วยภาษา C
- SQLite: ฐานข้อมูล SQL แบบ in-process ที่รองรับ ACID (1 พัน keys ใน /tmp/)
- RocksDB: ระบบจัดเก็บข้อมูลแบบ key-value แบบถาวรของ Facebook (1 ล้าน keys บน /dev/shm)
- WiredTiger: ระบบจัดเก็บข้อมูลแบบ key-value แบบถาวรของ MongoDB (1 ล้าน keys บน /dev/shm)
 |
|---|
| GitHub repository สำหรับ "Cache Benchmarks" ซึ่งรวมถึงการทดสอบประสิทธิภาพเทคโนโลยี caching ต่างๆ รวมทั้ง Valkey และ Redis |
ประสิทธิภาพ Pipeline ที่ยอดเยี่ยมของ Garnet
บางทีผลลัพธ์ที่น่าสนใจที่สุดมาจาก Garnet ซึ่งเป็น Redis-compatible cache ของ Microsoft ที่เขียนด้วย C# ซึ่งแสดงประสิทธิภาพที่ยอดเยี่ยมในสถานการณ์ high-pipeline แม้ว่าจะถูกสร้างบน managed runtime ที่มักเชื่อมโยงกับ performance overhead แต่ Garnet ก็บรรลุผลลัพธ์เหล่านี้ผ่านเทคนิคการปรับให้เหมาะสมแบบรุกรานที่หลีกเลี่ยง garbage collection และใช้ unmanaged memory อย่างกว้างขวาง
ปรัชญาการออกแบบของระบบนี้เกี่ยวข้องกับการหลีกเลี่ยงรูปแบบ C# ทั่วไปอย่าง async/await อย่างมีกลยุทธ์ แทนที่จะย้ายการดำเนินการ I/O ไปยัง network request threads โดยตรง แนวทางนี้แม้ว่าจะสร้างโค้ด C# ที่ไม่เป็นไปตามแบบแผน แต่ก็แสดงให้เห็นว่าการวิศวกรรมที่ระมัดระวังสามารถเอาชนะข้อจำกัดของภาษาที่รับรู้ได้
Multithreaded: การออกแบบระบบที่สามารถจัดการงานหลายอย่างพร้อมกันผ่าน processing threads ที่แตกต่างกัน ซึ่งโดยทั่วไปจะปรับปรุงประสิทธิภาพสำหรับการดำเนินการพร้อมกัน
ข้อมูลจำเพาะของสภาพแวดล้อมการทดสอบ:
- CPU: 3.1 GHz 12-Core Intel Xeon W (c8g.8xlarge 32-core ARM64 สำหรับการทดสอบบางส่วน)
- หน่วยความจำ: 64 GB 2666 MHz DDR4
- แพลตฟอร์ม: Linux (ยังไม่ได้ทดสอบบน Apple Silicon )
- ระยะเวลาการทดสอบ: 30 วินาทีต่อการวัดประสิทธิภาพ
- การดำเนินงาน: การดำเนินงานทั้งหมด 1,000,000 ครั้ง โดยมีอัตราส่วนการอ่าน 50%
ข้อกังวลเรื่องวิธีการทดสอบ
ข้อเสนอแนะจากชุมชนยังเน้นย้ำถึงปัญหาที่อาจเกิดขึ้นกับวิธีการทดสอบ โดยเฉพาะอย่างยิ่งเรื่องการเลือกใช้โปรโตคอลและการกำหนดค่าระบบ ผู้เชี่ยวชาญบางคนสังเกตว่า Memcached ถูกทดสอบโดยใช้โปรโตคอลข้อความแบบเก่าแทนที่จะเป็นโปรโตคอลไบนารีที่แนะนำ ซึ่งอาจส่งผลต่อความเป็นตัวแทนของผลลัพธ์สำหรับการใช้งานสมัยใหม่
นอกจากนี้ ยังเกิดคำถามเกี่ยวกับพฤติกรรมของแพลตฟอร์มการทดสอบ โดยมีการคงที่ของประสิทธิภาพเกิดขึ้นประมาณ 6-8 threads ในระบบส่วนใหญ่ แม้ว่าจะทำงานบนโปรเซสเซอร์ ARM64 32-core ก็ตาม สิ่งนี้ชี้ให้เห็นถึงข้อจำกัดทางสถาปัตยกรรมหรือปัญหาการกำหนดค่าที่อาจไม่สะท้อนประสิทธิภาพที่เหมาะสมที่สุดในโลกแห่งความเป็นจริง
การทดสอบประสิทธิภาพให้ข้อมูลเชิงลึกที่มีค่าเกี่ยวกับประสิทธิภาพของ cache และฐานข้อมูล แต่การตอบสนองของชุมชนเน้นย้ำถึงความสำคัญของการนำเสนอข้อมูลที่ชัดเจนและวิธีการทดสอบที่ครอบคลุมเมื่อประเมินประสิทธิภาพของระบบ เมื่อเทคโนโลยีเหล่านี้ยังคงพัฒนาต่อไป การทดสอบประสิทธิภาพดังกล่าวจึงเป็นเครื่องมือสำคัญสำหรับนักพัฒนาในการตัดสินใจเรื่องโครงสร้างพื้นฐาน โดยมีเงื่อนไขว่าผลลัพธ์ต้องถูกนำเสนอและตีความอย่างถูกต้อง
อ้างอิง: Cache Benchmarks