การเรียกฐานข้อมูล mutliple นั้นสำคัญมากกับการโทรผ่านเครือข่ายสำหรับเว็บ API หรือไม่?

ที่หนึ่งในนายจ้างของฉันเราทำงานกับ REST (แต่ก็ใช้กับ SOAP) API ด้วย ลูกค้าซึ่งเป็น UI ของแอปพลิเคชันจะโทรผ่านเว็บ (LAN ในการปรับใช้การผลิตทั่วไป) ไปยัง API API จะทำการเรียกไปยังฐานข้อมูล

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

แต่นั่นสำคัญจริงๆเหรอ? พิจารณาว่า UI ต้องทำการเรียกเครือข่ายไปยัง API มันค่อนข้างใหญ่ (ลำดับความสำคัญเป็นมิลลิวินาที) ฐานข้อมูลได้รับการปรับให้เหมาะสมเพื่อเก็บสิ่งต่าง ๆ ในหน่วยความจำและดำเนินการอ่านอย่างรวดเร็ว (เช่น SQL Server โหลดและเก็บทุกอย่างไว้ใน RAM และใช้ RAM ฟรีของคุณเกือบทั้งหมดถ้าทำได้)

TLDR: เป็นเรื่องสำคัญหรือไม่ที่จะต้องกังวลเกี่ยวกับการโทรฐานข้อมูลหลายครั้งเมื่อเราทำการโทรผ่านเครือข่ายผ่าน LAN หรือไม่? ถ้าเป็นเช่นนั้นทำไม

เพื่อความชัดเจนฉันกำลังพูดถึงลำดับความสำคัญ - ฉันรู้ว่าขึ้นอยู่กับข้อมูลเฉพาะ (ฮาร์ดแวร์เครื่องตัวเลือกของ API และ DB ฯลฯ ) ถ้าฉันมีสายที่ใช้ O (มิลลิวินาที) จะปรับให้เหมาะกับ DB การโทรที่มีลำดับความสำคัญน้อยลง หรือมีปัญหามากกว่านี้?

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

แต่นั่นสำคัญจริงๆเหรอ? พิจารณาว่า UI ต้องทำการเรียกเครือข่ายไปยัง API มันค่อนข้างใหญ่ (ลำดับความสำคัญเป็นมิลลิวินาที) ฐานข้อมูลได้รับการปรับให้เหมาะสมเพื่อเก็บสิ่งต่าง ๆ ในหน่วยความจำและดำเนินการอ่านอย่างรวดเร็ว (เช่น SQL Server โหลดและเก็บทุกอย่างไว้ใน RAM และใช้ RAM ฟรีของคุณเกือบทั้งหมดถ้าทำได้)

ลอจิก

ในทางทฤษฎีคุณถูกต้อง อย่างไรก็ตามมีข้อบกพร่องเล็กน้อยด้วยเหตุผลนี้:

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

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

3. วิธีคิดนี้ถือว่าเป็นกระบวนการเดียวในแต่ละครั้งหรือทำอย่างอื่นโดยไม่มีการทำงานพร้อมกัน สันนิษฐานว่าคำขอหนึ่งไม่สามารถมีอิทธิพลต่อประสิทธิภาพของคำขออื่น มีการแชร์ทรัพยากรเช่นดิสก์ I / O แบนด์วิดท์เครือข่ายพูลการเชื่อมต่อหน่วยความจำรอบการทำงานของ CPU ฯลฯ ดังนั้นการลดการใช้ฐานข้อมูลร่วมของการโทรฐานข้อมูลหนึ่งครั้งสามารถป้องกันไม่ให้เกิดการร้องขออื่น ๆ เมื่อฉันเข้าร่วมนายจ้างปัจจุบันของฉันครั้งแรกฝ่ายบริหารเชื่อว่าการปรับการสืบค้นฐานข้อมูล 3 วินาทีนั้นเป็นการเสียเวลา 3 วินาทีมีน้อยมากทำไมต้องเสียเวลากับมัน เราจะไม่ดีกว่าด้วย CDN หรือการบีบอัดหรืออย่างอื่นหรือ แต่ถ้าฉันสามารถสร้างคิวรี 3 วินาทีใน 1 วินาทีพูดโดยเพิ่มดัชนีนั่นคือการบล็อกน้อยลง 2/3 ใช้เวลาน้อยลง 2/3 ใช้เธรดและที่สำคัญยิ่งอ่านข้อมูลจากดิสก์น้อยลง

ทฤษฎี

มีความคิดเหมือนกันคือประสิทธิภาพการทำงานของซอฟแวร์เป็นเพียงเกี่ยวกับความเร็ว

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

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

สมมติฐาน

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

สถานที่ที่จะได้รับ murkey

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

นี่คือเหตุผล:

1. ฐานข้อมูลดีเยี่ยมในการอ่านข้อมูล พวกเขาเป็นเครื่องมือเก็บข้อมูล อย่างไรก็ตามตรรกะทางธุรกิจของคุณอาศัยอยู่ในแอปพลิเคชันของคุณ หากคุณสร้างกฎที่การเรียก API ทุกครั้งจะทำให้เกิดการเรียกฐานข้อมูลหนึ่งครั้งตรรกะธุรกิจของคุณอาจสิ้นสุดลงในฐานข้อมูล อาจจะไม่เป็นไร ระบบจำนวนมากทำเช่นนั้น แต่บางคนทำไม่ได้ มันเกี่ยวกับความยืดหยุ่น
2. บางครั้งเพื่อให้ได้การถอดรหัสที่ดีคุณต้องแยกการเรียกฐานข้อมูลออกเป็น 2 ตัวอย่างเช่นบางทีคำขอ HTTP ทุกครั้งจะถูกส่งผ่านตัวกรองความปลอดภัยทั่วไปซึ่งตรวจสอบจากฐานข้อมูลที่ผู้ใช้มีสิทธิ์การเข้าถึงที่ถูกต้อง หากเป็นเช่นนั้นให้ดำเนินการตามหน้าที่ที่เหมาะสมสำหรับ URL นั้น ฟังก์ชันนั้นอาจโต้ตอบกับฐานข้อมูล
3. การเรียกฐานข้อมูลในลูป นี่คือเหตุผลที่ฉันถามว่ามีหลายรายการ ในตัวอย่างข้างต้นคุณจะมีการโทรฐานข้อมูล 2 ครั้ง 2 ใช้ได้ 3 อาจไม่เป็นไร เอ็นไม่ดี ถ้าคุณเรียกใช้ฐานข้อมูลในลูปตอนนี้คุณได้สร้างประสิทธิภาพเชิงเส้นซึ่งหมายความว่ามันจะใช้เวลานานกว่าที่อยู่ในอินพุตของลูป ดังนั้นการบอกว่าเวลาเครือข่าย API ช้าที่สุดอย่างสมบูรณ์ที่สุดสามารถมองเห็นความผิดปกติเช่น 1% ของปริมาณการใช้งานของคุณใช้เวลานานเนื่องจากการวนรอบที่ยังไม่ได้ค้นพบที่เรียกฐานข้อมูล 10,000 ครั้ง
4. บางครั้งมีสิ่งต่าง ๆ ที่แอปของคุณดีกว่าเช่นการคำนวณที่ซับซ้อน คุณอาจจำเป็นต้องอ่านข้อมูลบางส่วนจากฐานข้อมูลทำการคำนวณบางอย่างจากนั้นส่งผลลัพธ์ให้พารามิเตอร์ผ่านการเรียกฐานข้อมูลตัวที่สอง (อาจจะเขียนผลลัพธ์บางส่วน) หากคุณรวมสิ่งเหล่านั้นไว้ในการโทรครั้งเดียว (เช่นขั้นตอนการจัดเก็บ) เพียงเพื่อเรียกฐานข้อมูลเพียงครั้งเดียวคุณได้บังคับให้คุณใช้ฐานข้อมูลสำหรับสิ่งที่เซิร์ฟเวอร์แอปอาจทำได้ดีกว่า
5. โหลดบาลานซ์: คุณมี 1 ฐานข้อมูล (สมมุติ) และโหลดแอ็พพลิเคชันเซิร์ฟเวอร์หลายโหลด ดังนั้นยิ่งแอปทำงานได้มากเท่าไหร่ฐานข้อมูลก็ยิ่งน้อยเท่านั้นยิ่งปรับขนาดได้ง่ายขึ้นเพราะโดยทั่วไปแล้วการเพิ่มแอพเซิร์ฟเวอร์ก็ง่ายกว่าการจำลองแบบฐานข้อมูลการตั้งค่า ขึ้นอยู่กับสัญลักษณ์แสดงหัวข้อก่อนหน้ามันอาจทำให้เหมาะสมในการเรียกใช้แบบสอบถาม SQL จากนั้นทำการคำนวณทั้งหมดในแอปพลิเคชันซึ่งกระจายไปทั่วหลายเซิร์ฟเวอร์แล้วเขียนผลลัพธ์เมื่อเสร็จสิ้น วิธีนี้จะให้ปริมาณงานที่ดีขึ้น (แม้ว่าเวลาธุรกรรมโดยรวมจะเท่ากัน)

TL; DR

TLDR: เป็นเรื่องสำคัญหรือไม่ที่จะต้องกังวลเกี่ยวกับการโทรฐานข้อมูลหลายครั้งเมื่อเราทำการโทรผ่านเครือข่ายผ่าน LAN หรือไม่? ถ้าเป็นเช่นนั้นทำไม

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

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

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

เราไม่สามารถบอกคุณได้

เราไม่ได้มีลักษณะการค้นหาของคุณ เราไม่ทราบว่าใช้เวลานานเท่าใดจึงจะเสร็จสมบูรณ์ เราไม่ทราบว่ามีค่าใช้จ่ายเท่าใดในแต่ละคำขอไปยังเซิร์ฟเวอร์ API ของคุณ เราไม่ทราบว่าลูกค้าของคุณกระจายตัวทางภูมิศาสตร์อย่างไร เป็นต้น

หากนี่เป็นสถานการณ์ที่ต้องมีการปรับให้เหมาะสมและเป็นสิ่งหนึ่งที่คุณสามารถตัดสินใจว่าจะแยกหรือเข้าร่วมการโทรด้วยกันคุณต้องเปรียบเทียบทั้งสองวิธี : ตัดสินใจสิ่งที่คุณปรับให้เหมาะสม (เวลาแฝง UI, โหลด CPU ของเซิร์ฟเวอร์ ฯลฯ ) และเลือกหนึ่งรายการที่บรรลุเป้าหมายการเพิ่มประสิทธิภาพของคุณได้ดียิ่งขึ้น

นอกเหนือจากนั้นสิ่งเดียวที่ฉันสามารถเพิ่มด้วยความมั่นใจสัมพัทธ์คือ:

ภายในคำขอเดียวคุณควรดำเนินการค้นหาทั้งหมดที่คุณต้องการเพื่อสร้างการตอบกลับ

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

สองความคิด:

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

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

ฉันไม่เห็นด้วยกับการจัดวางโค้ดอย่างง่ายฉันยอมรับว่าการเรียก API แต่ละครั้งควรเรียกขั้นตอนการจัดเก็บเดี่ยว (หรือฟังก์ชั่น db) ซึ่งจะมีหน้าที่รับผิดชอบในการกรอกคำขอ อาจมีมากกว่าหนึ่งขั้นตอนในกระบวนการ

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

ฉันเคยสังเกตเห็นว่าการเรียกเว็บเซอร์ครั้งเดียวสามารถแปลไปยังฐานข้อมูลการค้นหาได้ 500 ครั้ง - นี่ไม่ค่อยมีปัญหาเมื่อทั้งเว็บเซอร์และฐานข้อมูลอยู่ในเครื่องเดียวกัน เครื่อง

เห็นได้ชัดว่า 500 roundtrips ไปยังฐานข้อมูลนั้นค่อนข้างสุดขีด ฉันไม่แน่ใจว่าข้อกำหนดด้านประสิทธิภาพของคุณคืออะไร แต่ตามกฎทั่วไปแล้วฉันจะบอกว่าถ้าคุณอยู่ภายใต้การสืบค้นฐานข้อมูลประมาณ 10 ครั้งต่อการเรียกใช้ REST คุณไม่ควรพบกับประสิทธิภาพที่สำคัญ

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

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

เส้นทางการเพิ่มประสิทธิภาพที่นำเสนอเป็นเพียงวิธีที่ผิดในการดูสิ่งต่างๆ

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

บางครั้งการกระทำเดียวค่อนข้างซับซ้อน ตัวอย่างเช่นการดึงข้อมูลซึ่งรวมจากหลาย ๆ แหล่ง: อีกครั้งนี่ควรเป็นการโทรครั้งเดียว ไม่ว่าจะทำงานทั้งหมดหรือล้มเหลว

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

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

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