จะปรับปรุงประสิทธิภาพของ Java ได้อย่างไร?


23

ทีมมากกว่าที่ LMAX มีการนำเสนอเกี่ยวกับวิธีการที่พวกเขาสามารถที่จะทำ100k TPS ที่น้อยกว่า 1 มิลลิวินาทีแฝง พวกเขาได้รับการสนับสนุนขึ้นนำเสนอที่มีบล็อก , กระดาษทางเทคนิค (PDF)และรหัสที่มาของตัวเอง

เมื่อเร็ว ๆ นี้มาร์ตินฟาวเลอร์ได้ตีพิมพ์บทความที่ยอดเยี่ยมเกี่ยวกับสถาปัตยกรรม LMAXและระบุว่าตอนนี้พวกเขาสามารถจัดการคำสั่งได้หกล้านคำสั่งต่อวินาทีและเน้นขั้นตอนบางอย่างที่ทีมทำเพื่อเพิ่มขนาดของประสิทธิภาพ

จนถึงตอนนี้ฉันได้อธิบายแล้วว่ากุญแจสู่ความเร็วของ Business Logic Processor กำลังทำทุกอย่างตามลำดับในหน่วยความจำ เพียงแค่ทำสิ่งนี้ (และไม่มีอะไรโง่จริงๆ) ให้นักพัฒนาสามารถเขียนโค้ดที่สามารถประมวลผล 10K TPS

จากนั้นพวกเขาพบว่าการมุ่งเน้นไปที่องค์ประกอบง่ายๆของรหัสที่ดีสามารถนำสิ่งนี้มาสู่ช่วง 100K TPS สิ่งนี้ต้องการเพียงรหัสที่ได้รับการรับรองและวิธีการเล็ก ๆ เท่านั้นซึ่งสิ่งนี้จะช่วยให้ฮอตสปอตทำงานได้ดีขึ้นในการเพิ่มประสิทธิภาพและเพื่อให้ซีพียูมีประสิทธิภาพมากขึ้นในการแคชโค้ดขณะที่ทำงานอยู่

ความฉลาดเพิ่มขึ้นอีกเล็กน้อยเพื่อให้ได้ลำดับความสำคัญมากขึ้น มีหลายสิ่งที่ทีม LMAX พบว่าเป็นประโยชน์ในการเดินทาง หนึ่งคือการเขียนการใช้งานที่กำหนดเองของคอลเลกชัน Java ที่ได้รับการออกแบบให้เป็นมิตรกับแคชและระมัดระวังกับขยะ

อีกเทคนิคในการเข้าถึงระดับสูงสุดของประสิทธิภาพคือให้ความสนใจในการทดสอบประสิทธิภาพ ฉันสังเกตเห็นมานานแล้วว่าผู้คนพูดถึงเทคนิคต่าง ๆ มากมายเพื่อปรับปรุงประสิทธิภาพ แต่สิ่งหนึ่งที่สร้างความแตกต่างได้จริงๆคือการทดสอบ

ฟาวเลอร์กล่าวว่ามีหลายสิ่งที่พบ แต่เขาพูดถึงเพียงคู่

มีสถาปัตยกรรมห้องสมุดเทคนิคหรือ "สิ่ง" อื่น ๆ ที่มีประโยชน์ในการเข้าถึงระดับประสิทธิภาพดังกล่าวหรือไม่


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

มันจะเป็นการดีถ้าได้เรียนรู้ว่าเครื่องมือใดที่พวกเขาใช้เพื่อดูว่าโค้ดที่สร้างขึ้นนั้นทำงานอย่างไรในระบบ

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

คำตอบ:


21

มีเทคนิคทุกชนิดสำหรับการประมวลผลธุรกรรมที่มีประสิทธิภาพสูงและหนึ่งในบทความของ Fowler นั้นเป็นเพียงหนึ่งในหลาย ๆ เทคนิคที่มีเลือดไหลออกมา แทนที่จะแสดงเทคนิคมากมายที่อาจจะใช่หรือไม่เหมาะสมกับสถานการณ์ของทุกคนฉันคิดว่าเป็นการดีกว่าที่จะพูดคุยเกี่ยวกับหลักการพื้นฐานและวิธีที่ LMAX พูดถึงพวกเขาเป็นจำนวนมาก

สำหรับระบบประมวลผลธุรกรรมระดับสูงคุณต้องการทำสิ่งต่อไปนี้ให้มากที่สุด:

  1. ลดเวลาที่ใช้ในชั้นเก็บข้อมูลที่ช้าที่สุด จากเร็วที่สุดไปช้าที่สุดบนเซิร์ฟเวอร์สมัยใหม่คุณมี: CPU / L1 -> L2 -> L3 -> RAM -> Disk / LAN -> WAN การกระโดดจากแม้กระทั่งดิสก์แม่เหล็กที่ทันสมัยที่สุดไปจนถึง RAM ที่ช้าที่สุดคือมากกว่า 1,000 เท่าสำหรับการเข้าถึงต่อเนื่อง การเข้าถึงแบบสุ่มยิ่งแย่ลง

  2. ลดหรือขจัดเวลาที่ใช้ในการรอคอย นี่หมายถึงการแบ่งปันให้น้อยที่สุดเท่าที่จะเป็นไปได้และหากต้องแบ่งปันให้รัฐ

  3. กระจายภาระงาน ซีพียูไม่ได้เร็วขึ้นมากในช่วงหลายปีที่ผ่านมา แต่มันมีขนาดเล็กลงและ 8 คอร์นั้นค่อนข้างพบได้ทั่วไปบนเซิร์ฟเวอร์ นอกเหนือจากนั้นคุณยังสามารถกระจายงานผ่านเครื่องหลายเครื่องซึ่งเป็นแนวทางของ Google สิ่งที่ดีเกี่ยวกับเรื่องนี้คือมันชั่งทุกอย่างรวมถึง I / O

ตาม Fowler, LMAX ใช้วิธีการต่อไปนี้เพื่อแต่ละเหล่านี้:

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

  2. ใช้คิวที่ปลอดการล็อค ("disruptor") สำหรับกระแสข้อมูลเหตุการณ์ที่ป้อนเข้า ตรงกันข้ามกับความทนทานแบบดั้งเดิมคิวข้อความที่แตกหักไม่ได้ล็อคฟรีและในความเป็นจริงมักจะเกี่ยวข้องกับความเจ็บปวดช้าทำธุรกรรมกระจาย

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

LMAX ไม่ได้เป็นเพียงแนวทางเดียวของ OLTP ระดับสูง และถึงแม้ว่ามันจะยอดเยี่ยมในตัวของมันเอง แต่คุณไม่จำเป็นต้องใช้เทคนิคการตกเลือดเพื่อที่จะดึงประสิทธิภาพออกมา

จากหลักการข้างต้นทั้งหมด # 3 น่าจะเป็นสิ่งที่สำคัญที่สุดและมีประสิทธิภาพมากที่สุดเพราะจริงๆแล้วฮาร์ดแวร์มีราคาถูก หากคุณสามารถแบ่งปริมาณงานได้อย่างถูกต้องในช่วงครึ่งโหลและหลายสิบเครื่องดังนั้นท้องฟ้าจึงเป็นข้อ จำกัด สำหรับเทคนิคการคำนวณแบบขนานทั่วไป คุณจะประหลาดใจที่ปริมาณงานที่คุณสามารถดึงออกได้โดยไม่ต้องใช้อะไรเลยนอกจากคิวข้อความและผู้จัดจำหน่ายรอบ ๆ โรบิน เห็นได้ชัดว่ามันไม่ได้มีประสิทธิภาพเท่ากับ LMAX - จริง ๆ แล้วไม่ได้ปิด - แต่ปริมาณงานความหน่วงและความคุ้มค่าเป็นความกังวลที่แยกจากกันและที่นี่เรากำลังพูดถึงปริมาณผลผลิตโดยเฉพาะ

หากคุณมีความต้องการพิเศษแบบเดียวกันกับที่ LMAX ทำ - โดยเฉพาะอย่างยิ่งสถานะที่ใช้ร่วมกันซึ่งสอดคล้องกับความเป็นจริงทางธุรกิจซึ่งต่างจากตัวเลือกการออกแบบที่เร่งรีบ - ฉันขอแนะนำให้ลองใช้ส่วนประกอบของพวกเขาเพราะฉันไม่ได้เห็นอะไรมาก อื่นที่เหมาะสมกับความต้องการเหล่านั้น แต่ถ้าเรากำลังพูดถึงความสามารถในการปรับขนาดได้สูงฉันก็อยากแนะนำให้คุณทำการวิจัยเพิ่มเติมเกี่ยวกับระบบกระจายเพราะมันเป็นวิธีมาตรฐานที่องค์กรส่วนใหญ่ใช้ในปัจจุบัน (Hadoop และโครงการที่เกี่ยวข้อง ESB และสถาปัตยกรรมที่เกี่ยวข้อง, CQRS ซึ่งฟาวเลอร์ กล่าวถึงและอื่น ๆ )

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


การอภิปรายเกี่ยวกับหลักการที่เป็นพื้นฐานหลักการที่ดีและความคิดเห็นของคุณเป็นเลิศและ ... ถ้ากระดาษของพรานล่าสัตว์ไม่ได้มีการอ้างอิงในหมายเหตุการเดินเท้าไปยังแคชลืมขั้นตอนวิธีการen.wikipedia.org/wiki/Cache-oblivious_algorithm (ซึ่งเหมาะอย่างเข้าไป หมวดหมู่หมายเลข 1 ที่คุณมีด้านบน) ฉันจะไม่เคยเจอพวกเขา ดังนั้น ... ด้วยความเคารพในแต่ละหมวดหมู่ที่คุณมีข้างต้นคุณรู้เรื่อง 3 สิ่งที่คนควรรู้หรือไม่?
ดาโกต้าเหนือ

@Dakotah: ฉันจะไม่เริ่มกังวลเกี่ยวกับตำแหน่งของแคชเว้นแต่และจนกว่าฉันจะกำจัดดิสก์ I / O อย่างสมบูรณ์ซึ่งเป็นที่ที่ใช้เวลาส่วนใหญ่รออยู่ในแอปพลิเคชันส่วนใหญ่ นอกจากนั้นคุณหมายถึงอะไรโดย "สิ่งที่ 3 อันดับแรกที่คนควรรู้"? อันดับ 3 อะไรที่ต้องรู้เกี่ยวกับอะไร
Aaronaught

การกระโดดจากเวลาแฝงการเข้าถึง RAM (~ 10 ^ -9s) ไปยังดิสก์แฝงแม่เหล็ก (~ 10 ^ -3s โดยเฉลี่ย) เป็นคำสั่งที่มีขนาดมากกว่า 1,000 เท่า แม้แต่ SSD ยังมีเวลาเข้าถึงที่วัดได้ในหลายร้อยไมโครวินาที
Sedate Alien

@Sedate: เวลาในการตอบสนองใช่ แต่นี่เป็นคำถามเกี่ยวกับปริมาณงานมากกว่าเวลาแฝงแบบดิบและเมื่อคุณได้รับเวลาในการเข้าถึงที่ผ่านมาและความเร็วในการถ่ายโอนทั้งหมดดิสก์ก็ไม่ได้แย่ขนาดนั้น นั่นเป็นเหตุผลที่ฉันสร้างความแตกต่างระหว่างการเข้าถึงแบบสุ่มและต่อเนื่อง สำหรับสถานการณ์การเข้าถึงแบบสุ่มเป็นหลักมันจะกลายเป็นปัญหาความล่าช้า
Aaronaught

@Aaraught: เมื่ออ่านอีกครั้งฉันคิดว่าคุณถูกต้อง บางทีควรมีจุดที่การเข้าถึงข้อมูลทั้งหมดควรเป็นลำดับที่เป็นไปได้; ประโยชน์ที่สำคัญยังสามารถมีได้เมื่อเข้าถึงข้อมูลตามลำดับจาก RAM
Sedate Alien

10

ฉันคิดว่าบทเรียนที่ยิ่งใหญ่ที่สุดในการเรียนรู้จากสิ่งนี้คือคุณต้องเริ่มต้นด้วยพื้นฐาน:

  • อัลกอริทึมที่ดีโครงสร้างข้อมูลที่เหมาะสมและไม่ทำอะไรเลย "โง่มาก"
  • รหัสที่สมบูรณ์
  • การทดสอบประสิทธิภาพ

ในระหว่างการทดสอบประสิทธิภาพคุณใส่รหัสของคุณค้นหาคอขวดและแก้ไขทีละตัว

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


7

จะไม่แสดงความคิดเห็นเป็นพิเศษเกี่ยวกับรหัส LMAX เพราะฉันคิดว่ามันสืบทอดมาพอสมควร แต่นี่เป็นตัวอย่างของสิ่งที่ฉันทำซึ่งส่งผลให้มีการปรับปรุงประสิทธิภาพที่วัดได้อย่างมีนัยสำคัญ

และเช่นเคยนี่เป็นเทคนิคที่ควรนำมาใช้เมื่อคุณรู้ว่าคุณมีปัญหาและจำเป็นต้องปรับปรุงประสิทธิภาพ - มิฉะนั้นคุณมีแนวโน้มที่จะเพิ่มประสิทธิภาพก่อนวัยอันควร

  • ใช้โครงสร้างข้อมูลที่ถูกต้องและสร้างโครงสร้างที่กำหนดเองหากจำเป็น - ออกแบบโครงสร้างข้อมูลที่ถูกต้องแคระการปรับปรุงที่คุณจะได้รับจากการปรับให้เหมาะสมแบบไมโครดังนั้นทำสิ่งนี้ก่อน หากอัลกอริทึมของคุณขึ้นอยู่กับประสิทธิภาพของการเข้าถึงแบบสุ่ม O (1) แบบสุ่มจำนวนมากตรวจสอบให้แน่ใจว่าคุณมีโครงสร้างข้อมูลที่รองรับสิ่งนี้! เป็นมูลค่าการกระโดดผ่านห่วงบางอย่างเพื่อให้ได้สิทธินี้เช่นการหาวิธีที่คุณสามารถแสดงข้อมูลของคุณในอาร์เรย์เพื่อใช้ประโยชน์จากการอ่านอย่างรวดเร็ว O (1) การจัดทำดัชนี
  • CPU เร็วกว่าการเข้าถึงหน่วยความจำ - คุณสามารถทำการคำนวณได้ค่อนข้างมากในเวลาที่ใช้ในการสร้างหน่วยความจำแบบสุ่มหนึ่งหน่วยหากหน่วยความจำไม่ได้อยู่ในแคช L1 / L2 โดยปกติแล้วมันจะมีค่าในการคำนวณถ้ามันช่วยคุณในการอ่านหน่วยความจำ
  • ช่วยคอมไพเลอร์ JIT ด้วยการสร้างฟิลด์วิธีการและคลาสสุดท้ายให้เปิดใช้งานการเพิ่มประสิทธิภาพเฉพาะที่ช่วยให้คอมไพเลอร์ JIT ได้จริง ตัวอย่างเฉพาะ:

    • คอมไพเลอร์สามารถสันนิษฐานได้ว่าคลาสสุดท้ายไม่มีคลาสย่อยดังนั้นสามารถเปลี่ยนการเรียกใช้เมธอดเสมือนเป็นการเรียกใช้เมธอดแบบสแตติก
    • คอมไพเลอร์สามารถจัดการฟิลด์สุดท้ายแบบสแตติกเป็นค่าคงที่สำหรับการปรับปรุงประสิทธิภาพที่ดีโดยเฉพาะอย่างยิ่งหากใช้ค่าคงที่ในการคำนวณที่สามารถคำนวณได้ในเวลารวบรวม
    • หากเขตข้อมูลที่มีวัตถุ Java ถูกเริ่มต้นเป็นขั้นสุดท้ายเครื่องมือเพิ่มประสิทธิภาพสามารถกำจัดทั้งการตรวจสอบค่า Null และการจัดส่งเมธอดเสมือน ดี
  • แทนที่คลาสของคอลเล็กชันด้วยอาร์เรย์ - ผลลัพธ์นี้ในโค้ดที่อ่านได้น้อยกว่าและมีความยุ่งยากในการบำรุงรักษา แต่เกือบจะเร็วกว่าเสมอเนื่องจากมันทำการลบเลเยอร์ของทางอ้อมและผลประโยชน์จากการเพิ่มประสิทธิภาพการเข้าถึงอาเรย์จำนวนมาก โดยทั่วไปแล้วความคิดที่ดีในลูปภายใน / โค้ดที่ไวต่อประสิทธิภาพหลังจากที่คุณระบุว่าเป็นคอขวด แต่ควรหลีกเลี่ยงมิฉะนั้นเพื่อความสะดวกในการอ่าน!

  • ใช้แบบดั้งเดิมเมื่อใดก็ตามที่เป็นไปได้ - แบบดั้งเดิมนั้นเร็วกว่าการเทียบเท่าแบบวัตถุ โดยเฉพาะอย่างยิ่งการชกมวยเพิ่มค่าใช้จ่ายจำนวนมากและอาจทำให้เกิดการหยุด GC ที่น่ารังเกียจ ไม่อนุญาตให้วางกล่องแบบดั้งเดิมหากคุณสนใจเกี่ยวกับประสิทธิภาพ / ความหน่วงแฝง

  • ลดการล็อคระดับต่ำ - ล็อคมีราคาแพงมากในระดับต่ำ ค้นหาวิธีหลีกเลี่ยงการล็อกทั้งหมดหรือล็อกในระดับหยาบเพื่อให้คุณต้องล็อคนาน ๆ ครั้งในบล็อกข้อมูลขนาดใหญ่และรหัสระดับต่ำสามารถดำเนินการต่อได้โดยไม่ต้องกังวลเกี่ยวกับปัญหาการล็อคหรือการทำงานพร้อมกัน

  • หลีกเลี่ยงการจัดสรรหน่วยความจำ - นี่อาจทำให้คุณช้าลงโดยรวมเนื่องจากการรวบรวมขยะ JVM นั้นมีประสิทธิภาพอย่างไม่น่าเชื่อ แต่มีประโยชน์มากถ้าคุณพยายามลดเวลาในการตอบสนองที่ต่ำมากและจำเป็นต้องลด GC ชั่วคราว มีโครงสร้างข้อมูลพิเศษที่คุณสามารถใช้เพื่อหลีกเลี่ยงการจัดสรร - โดยเฉพาะอย่างยิ่งhttp://javolution.org/ ไลบรารี่ที่ยอดเยี่ยมและโดดเด่นสำหรับสิ่งเหล่านี้

ผมไม่เห็นด้วยกับวิธีการทำขั้นสุดท้าย JIT สามารถเข้าใจได้ว่าวิธีการใด ๆ ที่ไม่เคยถูกแทนที่ นอกจากนี้ในกรณีที่โหลดคลาสย่อยในภายหลังสามารถยกเลิกการปรับให้เหมาะสม นอกจากนี้โปรดทราบว่า"หลีกเลี่ยงการจัดสรรหน่วยความจำ"อาจทำให้งานของ GC หนักขึ้นและทำให้คุณช้าลง - ดังนั้นควรใช้ด้วยความระมัดระวัง
maaartinus

@maaartinus: เกี่ยวกับfinalJIT บางคนอาจจะคิดออกว่าคนอื่น ๆ อาจจะไม่ มันขึ้นอยู่กับการใช้งาน (เช่นเดียวกับเคล็ดลับการปรับแต่งประสิทธิภาพมากมาย) เห็นด้วยเกี่ยวกับการจัดสรร - คุณต้องเปรียบเทียบสิ่งนี้ โดยปกติฉันพบว่าเป็นการดีกว่าที่จะกำจัดการจัดสรร แต่ YMMV
mikera

4

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

  • สำหรับนักพัฒนาที่ใช้ในการสอบถามและล็อคแบบดั้งเดิมการเขียนโค้ดสำหรับวิธีการใหม่อาจรู้สึกเหมือนขี่ม้าป่า อย่างน้อยนั่นก็เป็นประสบการณ์ของฉันเมื่อทำการทดลองกับPhaserซึ่งแนวคิดถูกกล่าวถึงในเอกสารทางเทคนิค LMAX ในแง่ที่ว่าผมจะบอกว่าการต่อสู้นี้วิธีการซื้อขายล็อคสำหรับการแข่งขันนักพัฒนาสมอง

จากที่กล่าวมาข้างต้นฉันคิดว่าผู้ที่เลือก Disruptor และวิธีการที่คล้ายกันดีกว่าควรตรวจสอบให้แน่ใจว่าพวกเขามีทรัพยากรการพัฒนาเพียงพอที่จะรักษาโซลูชัน

โดยรวมแล้ววิธีการของ Disruptor นั้นค่อนข้างจะมีแนวโน้มที่ดีสำหรับฉัน แม้ว่า บริษัท ของคุณจะไม่สามารถใช้ประโยชน์ได้เช่นด้วยเหตุผลที่กล่าวมาข้างต้นให้ลองโน้มน้าวฝ่ายบริหารของคุณให้ "ลงทุน" ความพยายามในการศึกษามัน (และSEDAโดยทั่วไป) - เพราะหากพวกเขาไม่มีโอกาส ลูกค้าของพวกเขาจะปล่อยให้พวกเขาในความโปรดปรานของการแก้ปัญหาการแข่งขันที่ต้องใช้เซิร์ฟเวอร์น้อย 4x, 8x ฯลฯ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.