คำถามติดแท็ก scalability

เมื่อเร็ว ๆ นี้ฉันอ่านมากเกี่ยวกับ noSQL DBMSs ผมเข้าใจCAP ทฤษฎีบท , กรดกฎBASEกฎและทฤษฎีพื้นฐาน แต่ไม่พบทรัพยากรใด ๆ ว่าทำไม noSQL จึงสามารถปรับขนาดได้ง่ายกว่า RDBMS (เช่นในกรณีของระบบที่ต้องใช้เซิร์ฟเวอร์ DB จำนวนมาก) ฉันเดาว่าการรักษาข้อ จำกัด และกุญแจต่างประเทศต้องใช้ทรัพยากรและเมื่อมีการกระจาย DBMS มันก็ซับซ้อนกว่ามาก แต่ฉันคาดหวังว่าจะมีมากกว่านี้ ใครช่วยกรุณาอธิบายว่า noSQL / SQL ส่งผลกระทบต่อความสามารถในการปรับขนาดได้หรือไม่?

98 sql  nosql  scalability 

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

34 design  architecture  websites  scalability 

ฉันต้องเขียนผู้จัดการระบบการแจ้งเตือน นี่คือข้อกำหนดของฉัน: ฉันต้องสามารถส่งการแจ้งเตือนบนแพลตฟอร์มที่แตกต่างกันซึ่งอาจแตกต่างกันโดยสิ้นเชิง (สำหรับตัวอย่างฉันต้องสามารถส่ง SMS หรืออีเมลได้) บางครั้งการแจ้งเตือนอาจเหมือนกันสำหรับผู้รับทุกคนสำหรับแพลตฟอร์มที่กำหนด แต่บางครั้งอาจเป็นการแจ้งเตือนต่อผู้รับ (หรือหลายคน) ต่อแพลตฟอร์ม การแจ้งเตือนแต่ละครั้งสามารถมีส่วนของข้อมูลเฉพาะแพลตฟอร์มได้ (สำหรับตัวอย่าง MMS ที่มีเสียงหรือภาพ) ระบบจำเป็นต้องปรับขนาดได้ฉันต้องสามารถส่งการแจ้งเตือนจำนวนมากโดยไม่ต้องหยุดทำงานทั้งแอปพลิเคชันหรือเซิร์ฟเวอร์ มันเป็นกระบวนการสองขั้นตอนแรกที่ลูกค้าอาจพิมพ์ข้อความและเลือกแพลตฟอร์มที่จะส่งไปและควรสร้างการแจ้งเตือนเพื่อประมวลผลแบบเรียลไทม์ในภายหลัง จากนั้นระบบจะต้องส่งการแจ้งเตือนไปยังผู้ให้บริการแพลตฟอร์ม สำหรับตอนนี้ฉันจบลงด้วยบางอย่าง แต่ฉันไม่รู้ว่ามันจะปรับขนาดได้หรือถ้ามันเป็นการออกแบบที่ดี ฉันว่าวัตถุต่อไปนี้ (ในภาษาเทียม): Notificationวัตถุทั่วไป: class Notification { String $message; Payload $payload; Collection<Recipient> $recipients; } ปัญหาเกี่ยวกับวัตถุต่อไปนี้จะเกิดอะไรขึ้นถ้าฉันมีผู้รับ 1,000,000? แม้ว่าRecipientวัตถุนั้นจะเล็กมากมันก็จะใช้หน่วยความจำมากเกินไป ฉันสามารถสร้างการแจ้งเตือนได้หนึ่งรายการต่อผู้รับ แต่ผู้ให้บริการแพลตฟอร์มบางรายกำหนดให้ฉันส่งเป็นชุดซึ่งหมายความว่าฉันต้องกำหนดหนึ่งการแจ้งเตือนที่มีผู้รับหลายคน การแจ้งเตือนที่สร้างขึ้นแต่ละครั้งสามารถเก็บไว้ในที่เก็บข้อมูลถาวรเช่น DB หรือ Redis มันจะเป็นการดีหรือไม่ที่จะรวมกันในภายหลังเพื่อให้แน่ใจว่าสามารถปรับขนาดได้หรือไม่? ในขั้นตอนที่สองฉันต้องดำเนินการการแจ้งเตือนนี้ แต่ฉันจะแยกแยะการแจ้งเตือนกับผู้ให้บริการแพลตฟอร์มที่เหมาะสมได้อย่างไร ฉันควรใช้วัตถุเช่นMMSNotificationขยายabstract Notificationหรือไม่ หรือสิ่งที่ต้องการNotification.setType('MMS')? เพื่อให้สามารถประมวลผลการแจ้งเตือนจำนวนมากในเวลาเดียวกันฉันคิดว่าระบบคิวการส่งข้อความเช่น RabbitMQ อาจเป็นเครื่องมือที่เหมาะสม …

32 design  architecture  performance  object-oriented-design  scalability 

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

32 javascript  jquery  scalability 

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

29 web-applications  scalability  distributed-computing 

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

24 database  sql  nosql  scalability 

เฟรมเวิร์กเว็บจำนวนมากเช่นFlaskหรือDjangoใช้SQLiteเป็นฐานข้อมูลเริ่มต้น SQLiteนั้นน่าสนใจเพราะมันรวมอยู่ในไพ ธ อนและค่าใช้จ่ายในการจัดการค่อนข้างต่ำ อย่างไรก็ตามไซต์การผลิตสาธารณะที่มีปริมาณการใช้งานสูงส่วนใหญ่ใช้ฐานข้อมูลที่หนักกว่า: mySQL, Oracle หรือ postgresql คำถาม : สมมติ: ปริมาณการใช้ของไซต์อยู่ในระดับปานกลางและการเข้าถึงแบบอ่าน / เขียนในฐานข้อมูลจะเกิดขึ้นพร้อมกัน เราจะใช้SQLAlchemyกับล็อคการเขียน SQLite (แม้ว่าความคิดเห็นนี้ทำให้ฉันกังวลเล็กน้อย) ฐานข้อมูลอาจมีบันทึก 60,000 รายการ โครงสร้างข้อมูลไม่ต้องการคุณสมบัติขั้นสูงที่พบในฐานข้อมูลที่หนักกว่า มีกรณีที่น่าสนใจต่อการเกิดพร้อมกันของSQLiteสำหรับเว็บไซต์ที่ทำหน้าที่เป็นเครื่องมือภายในองค์กรที่มีปริมาณการใช้งานปานกลางหรือไม่? ถ้าเป็นเช่นนั้นเงื่อนไขใดที่ทำให้SQLiteมีปัญหาการทำงานพร้อมกัน? ฉันกำลังมองหาสาเหตุที่เฉพาะเจาะจงที่เป็นที่รู้จักแทนการกลัวนิ้วชี้โดยทั่วไป / ไม่พร้อมเพรียง

23 sql  frameworks  scalability  web-framework  sqlite 

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

22 scalability  users 

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

22 design  scalability  message-queue 

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

22 development-process  scalability  bdd  integration-tests 

ฉันได้อ่านเกี่ยวกับปัญหา C10K แล้วและโดยเฉพาะอย่างยิ่งบันทึกย่อนั้นเป็นส่วนที่อ้างอิงถึงเซิร์ฟเวอร์ I / O อะซิงโครนัส http://www.kegel.com/c10k.html#aio ฉันเชื่อว่าสิ่งนี้จะสรุปสิ่งที่ Node.js ทำบนเซิร์ฟเวอร์โดยอนุญาตให้เธรดประมวลผลคำขอของผู้ใช้ในขณะที่พึ่งพา I / O อินเตอร์รัปต์ (เหตุการณ์) เพื่อแจ้งเตือนเธรดงานที่เสร็จสมบูรณ์แทนที่จะให้เธรดรับผิดชอบ งาน CPU แบบเต็ม เธรดสามารถดำเนินการกับสิ่งอื่น ๆ (ไม่ปิดกั้น) และได้รับแจ้งเมื่องานเสร็จ (เช่นพบไฟล์หรือบีบอัดวิดีโอ) ซึ่งหมายความว่าเธรดจะมีซ็อคเก็ต 'พร้อมใช้งาน' มากขึ้นและสำหรับผู้ใช้บนเซิร์ฟเวอร์ จากนั้นฉันก็พบสิ่งนี้: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html ผู้เขียนอ้างว่าถึงแม้ว่าเฟรมเวิร์กที่ขับเคลื่อนด้วยเหตุการณ์ (เธรดที่ขัดจังหวะ) อาจทำให้เธรดว่าง แต่จริงๆแล้วมันไม่ได้ลดปริมาณงานที่ CPU ต้องทำ! เหตุผลที่นี่คือถ้าหากผู้ใช้ร้องขอให้บีบอัดวิดีโอที่พวกเขาอัปโหลด CPU จะต้องทำงานจริงและจะบล็อกในขณะที่มันทำ (เพื่อประโยชน์ของความเรียบง่ายให้ลืมเรื่องขนานที่นี่ - เว้นแต่คุณ รู้ดีกว่า!) ฉันเป็น coder ที่ตรงไปตรงมาไม่ใช่ผู้ดูแลเซิร์ฟเวอร์หรืออะไรแบบนั้น ฉันแค่สนใจที่จะรู้ว่า: Node.js เป็นของขวัญจากเทพเจ้าแห่ง 'คลาวด์คอมพิวติ้ง' …

21 scalability  node.js  server 

ฉันถูกขอให้นำเสนอทางเทคนิคเล็กน้อยเกี่ยวกับความยืดหยุ่นในการใช้งานเฉพาะ แอพพลิเคชั่นนี้พัฒนาขึ้นโดยใช้ Java, Spring MVC, Hibernate ฉันมีสิทธิ์เข้าถึงซอร์สโค้ดของแอปพลิเคชัน ฉันจะวัดความสามารถในการปรับขนาดซอฟต์แวร์ (โดยใช้แหล่งที่มา) และตัวชี้วัดใดที่ฉันต้องดูแลเมื่อวัดความสามารถในการปรับขนาดซอฟต์แวร์ได้อย่างไร

21 scalability  metrics 

สมมติว่าคุณทำงานให้กับ บริษัท และสิ่งที่คุณทำคือการพัฒนาซอฟต์แวร์สำหรับพวกเขา คุณไม่มีความคิดในภาพรวมหรืออาจจะเล็กน้อย สิ่งที่คุณมีคืองานที่มอบหมายให้คุณผ่านระบบติดตามปัญหา คุณได้รับงานคุณทำให้งานเป็นไปตามที่งานอธิบายคุณส่งงานกลับมา ชอบเพิ่ม 2 จำนวนเต็ม: function add(a,b){return a + b;} แต่ต่อมาเมื่อโครงการดำเนินไปข้างหน้าคุณจะสังเกตเห็นว่าในขณะที่addมีความซับซ้อนมากขึ้นคุณรู้ว่ามันควรจะต้องมีรูปแบบของสถาปัตยกรรมมากกว่าฟังก์ชั่นที่เพิ่มพารามิเตอร์และส่งกลับค่า อย่างไรก็ตามคุณไม่ทราบว่า addในสถานที่แรกทั้งหมดที่พวกเขาต้องการก็คือง่ายๆที่ คุณไม่ได้คาดหวังว่าการเพิ่มจะซับซ้อนนัก โครงการดำเนินไปด้วยคุณสมบัติที่มากขึ้นซึ่งคุณไม่ได้คาดหวังไว้ตั้งแต่แรก และในที่สุดคุณก็เก็บซ้อนแฮ็คและเลเยอร์ตามเลเยอร์ของฟังก์ชั่นเพื่อหลีกเลี่ยงการทำลาย / เขียนรหัสที่มีอยู่ใหม่ คุณรับมือกับสถานการณ์เหล่านี้อย่างไร? คุณต่อสู้กับหนี้ทางเทคนิคในฐานะ "ผู้พัฒนาที่ต่ำที่สุด" ได้อย่างไร? ชี้แจง: คุณคือ "implementer" ซึ่งต่ำที่สุดในลำดับชั้น คุณเห็นปัญหา แต่ไม่ได้พูดกับเรื่องนี้ ฉันไม่ได้ระบุปริมาณหนี้ทางเทคนิคหรือมองหาเครื่องมือ เกี่ยวกับ"ซ้ำ" ที่สาม การ Refactoring & Rewrite - คุณถูกล็อคในงานของคุณ คุณไม่ได้รับค่าตอบแทนในการทำสิ่งพิเศษ ภาพรวมสถาปัตยกรรม - คุณรู้ระบบโดยรวม แต่ไม่มีแนวคิดเกี่ยวกับสถาปัตยกรรม Code Freeze - ไม่ใช่การโทรของคุณ …

20 architecture  software  scalability  maintainability  technical-debt 

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

20 architecture  project  scalability  risk-assesment 

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

17 testing  optimization  scalability