เราประมวลผลข้อความผ่านบริการที่หลากหลาย (หนึ่งข้อความจะสัมผัสถึง 9 บริการก่อนที่จะเสร็จสิ้นแต่ละคนทำหน้าที่เฉพาะที่เกี่ยวข้องกับ IO) ตอนนี้เรามีการรวมกันของกรณีที่เลวร้ายที่สุด (อนุกรมข้อมูลสัญญา XML) และกรณีที่ดีที่สุด (MSMQ ในหน่วยความจำ) สำหรับประสิทธิภาพ
ลักษณะของข้อความหมายถึงข้อมูลที่ต่อเนื่องของเราสิ้นสุดลงประมาณ 12-15 กิโลไบต์และเราประมวลผลข้อความประมาณ 4 ล้านข้อความต่อสัปดาห์ ข้อความถาวรใน MSMQ นั้นช้าเกินไปสำหรับเราและเมื่อข้อมูลเติบโตขึ้นเราก็รู้สึกกดดันจากไฟล์ที่แม็พหน่วยความจำของ MSMQ เซิร์ฟเวอร์อยู่ที่ 16GB ของการใช้หน่วยความจำและเพิ่มขึ้นเพียงเพื่อรอคิว ประสิทธิภาพยังลดลงเมื่อการใช้หน่วยความจำสูงเนื่องจากเครื่องเริ่มทำการแลกเปลี่ยน เรากำลังทำพฤติกรรมการล้างข้อมูลด้วยตนเองด้วย MSMQ
ฉันรู้สึกว่ามีส่วนหนึ่งที่เราทำผิดที่นี่ ฉันพยายามใช้ RavenDB เพื่อคงข้อความไว้และเพียงรอคิวตัวระบุ แต่ประสิทธิภาพการทำงานนั้นช้ามาก (ดีที่สุด 1,000 ข้อความต่อนาทีอย่างดีที่สุด) ฉันไม่แน่ใจว่าเป็นผลมาจากการใช้รุ่นพัฒนาหรืออะไร แต่เราต้องการปริมาณงานที่สูงขึ้น [1] แนวคิดนี้ทำงานได้ดีในทางทฤษฎี แต่ประสิทธิภาพไม่ได้ขึ้นอยู่กับภารกิจ
รูปแบบการใช้มีบริการหนึ่งที่ทำหน้าที่เป็นเราเตอร์ซึ่งจะอ่านทั้งหมด บริการอื่น ๆ จะแนบข้อมูลตามเบ็ดของบุคคลที่สามและส่งต่อกลับไปที่เราเตอร์ วัตถุส่วนใหญ่จะถูกสัมผัส 9-12 ครั้งแม้ว่าประมาณ 10% จะถูกบังคับให้วนรอบในระบบนี้สักครู่จนกว่าบุคคลที่สามจะตอบสนองอย่างเหมาะสม ขณะนี้บริการนี้มีบัญชีและมีพฤติกรรมการนอนหลับที่เหมาะสมเนื่องจากเราใช้ฟิลด์ลำดับความสำคัญของข้อความด้วยเหตุนี้
ดังนั้นคำถามของฉันคือสแต็คที่เหมาะสำหรับการส่งข้อความระหว่างเครื่องที่แยกจากกัน แต่เป็น LAN ในสภาพแวดล้อม C # / Windows ปกติแล้วฉันจะเริ่มต้นด้วย BinaryFormatter แทนที่จะเป็น XML serialization แต่นั่นก็เป็นช่องโหว่ของกระต่ายหากวิธีที่ดีกว่าคือการลดการทำให้เป็นอนุกรมลงในที่เก็บเอกสาร ดังนั้นคำถามของฉัน
[1]: ลักษณะของธุรกิจของเราหมายถึงยิ่งเราประมวลผลข้อความได้เร็วเท่าไหร่เราก็ยิ่งมีรายได้มากเท่านั้น เราได้รับการพิสูจน์เชิงประจักษ์แล้วว่าการประมวลผลข้อความในสัปดาห์ต่อมาหมายความว่าเรามีโอกาสน้อยที่จะทำเงินนั้น ในขณะที่ประสิทธิภาพการทำงานของ "1,000 ต่อนาที" ฟังดูเร็วมาก แต่เราต้องการจำนวนที่สูงกว่า 10k / นาที เพียงเพราะฉันให้ตัวเลขในข้อความต่อสัปดาห์ไม่ได้หมายความว่าเรามีทั้งสัปดาห์ในการประมวลผลข้อความเหล่านั้น
=============== แก้ไข:
ข้อมูลเพิ่มเติม
จากความคิดเห็นฉันจะเพิ่มคำอธิบายบางอย่าง:
ฉันไม่แน่ใจว่าการทำให้เป็นอันดับเป็นคอขวดของเรา ฉันได้ทำการเปรียบเทียบแอปพลิเคชั่นและในขณะที่การทำให้เป็นอนุกรมจะปรากฏขึ้นในกราฟความร้อนมีความรับผิดชอบเพียง 2.5-3% ของการใช้งาน CPU ของบริการ
ฉันส่วนใหญ่กังวลเกี่ยวกับความคงทนของข้อความของเราและการใช้ MSMQ ในทางที่ผิด เรากำลังใช้ข้อความที่ไม่ทำธุรกรรมและไม่ถาวรดังนั้นเราจึงสามารถรักษาประสิทธิภาพการทำงานของคิวไว้ได้และฉันต้องการให้มีข้อความถาวรอย่างน้อยที่สุดเพื่อให้พวกเขาอยู่รอดในการรีบูต
การเพิ่มแรมเพิ่มเติมเป็นการวัดที่หยุดชั่วคราว เครื่องได้หายไปจาก 4GB -> RAM 16 GB แล้วและมันก็ยากขึ้นที่จะนำมันลงมาเพิ่มอีกเรื่อย ๆ
เนื่องจากรูปแบบการจัดเส้นทางดาวของแอปพลิเคชันครึ่งเวลาที่วัตถุถูกผุดแล้วผลักไปยังคิวที่ไม่เปลี่ยนแปลงเลย สิ่งนี้ให้ยืมตัวเองอีกครั้ง (IMO) เพื่อจัดเก็บในที่เก็บคีย์ - ค่าบางชนิดที่อื่นและเพียงแค่ส่งข้อความตัวระบุ
รูปแบบการกำหนดเส้นทางดาวนั้นมีความสำคัญอย่างยิ่งต่อแอปพลิเคชันและจะไม่เปลี่ยนแปลง เราไม่สามารถใช้แอปพลิเคชั่นตะขาบได้เพราะทุกชิ้นที่ทำงานแบบอะซิงโครนัส (ในแบบสำรวจ) และเราต้องการรวบรวมพฤติกรรมการลองใหม่ในที่เดียว
ตรรกะของแอปพลิเคชันนั้นเขียนด้วย C # วัตถุนั้นเป็น POCO ที่ไม่เปลี่ยนรูปแบบสภาพแวดล้อมการปรับใช้เป้าหมายคือ Windows Server 2012 และเราได้รับอนุญาตให้ตั้งเครื่องเพิ่มเติมหากมีซอฟต์แวร์เฉพาะใน Linux ที่รองรับ
เป้าหมายของฉันคือการรักษาปริมาณงานในปัจจุบันในขณะที่ลดการใช้หน่วยความจำและเพิ่มความทนทานต่อความผิดพลาดด้วยค่าใช้จ่ายขั้นต่ำ