การขาด“ บิตพาริตี้” ระหว่างเว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์ DB นั้นส่งผลกระทบต่อประสิทธิภาพการทำงานหรือไม่


10

ฉันได้พบกับผู้จำหน่ายซอฟต์แวร์วันนี้เกี่ยวกับโครงสร้างพื้นฐานที่แนะนำสำหรับการปรับใช้แอปพลิเคชันเฉพาะ แอปพลิเคชันต้องการเซิร์ฟเวอร์สองเครื่อง: เซิร์ฟเวอร์แอปสำหรับหน้าเว็บเซิร์ฟเวอร์ (. NET, Windows) และฐานข้อมูล (SQL Server) ผู้ขายอ้างว่าเซิร์ฟเวอร์ทั้งสองนี้ต้องมี "บิตพาริตี" สิ่งที่พวกเขาหมายถึงคือถ้าเซิร์ฟเวอร์แอปเป็น 32 บิต SQL Server ควรเป็น 32 บิตหรือถ้าแอปนั้นเป็น 64 บิต SQL Server จะเป็น 64 บิต มิฉะนั้นประสิทธิภาพจะได้รับผลกระทบในทางลบ

มันดูน่าหัวเราะสำหรับฉัน เซิร์ฟเวอร์มีความเป็นอิสระและสื่อสารผ่านเครือข่ายเท่านั้น โปรโตคอลเครือข่ายไม่มีส่วนเกี่ยวข้องกับ "บิตเนส" ของโปรเซสเซอร์บนเซิร์ฟเวอร์ใดเครื่องหนึ่ง

ฉันผิดหรือเปล่า? มีเหตุผลใดที่ความไม่ตรงกันที่แท้จริงอาจส่งผลเสียต่อประสิทธิภาพการทำงานหรือไม่

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


ทุกสิ่งเท่าเทียมกันเขาคิดว่า 32 และ 32 วิ่งเร็วกว่า 32 และ 64 หรือไม่?
JeffO

นั่นคือสิ่งที่ผู้ขายอ้างสิทธิ์ใช่ ประสิทธิภาพของ 32,32 หรือ 64,64 สูงกว่า 32,64 หรือ 64,32
RationalGeek

ให้พวกมันตั้งค่าสองรูปแบบของระบบ จากนั้นทดสอบความเครียด ซื้อรุ่นที่ถูกที่สุดที่ตรงกับความต้องการของคุณ
Martin York

คำตอบ:


10

ฉันคิดว่าเป็นไปได้ว่าพวกเขารู้ว่ามีปฏิสัมพันธ์เฉพาะระหว่างผลิตภัณฑ์ทั้งสองที่ทำให้เกิดปัญหาเมื่อมีความไม่ตรงกัน (แต่ฉันสงสัยจริงๆ - ฉันใส่ประมาณ 10: 1 ซึ่งผู้ขายเต็มไปด้วยมัน)

คุณอาจต้องการค้นหา serverfault สำหรับคำถามเกี่ยวกับผลกระทบของการจับคู่ที่ไม่ตรงกัน แต่ฉันสงสัยว่าคุณจะพบมากเพราะฉันสงสัยว่ามีปัญหาใด ๆ


1
+1 ฉันคิดว่าคุณตายแล้ว อาจมีข้อควรพิจารณาด้านประสิทธิภาพในแต่ละกล่องเป็นอย่างดี แต่ผ่านเครือข่ายไม่ว่าจะเป็น 32 บิตหรือ 64 บิตก็ตาม
Moo-Juice

1
เป็นไปได้ไหม? ฉันไม่สามารถนึกถึงสถานการณ์หนึ่งที่เป็นไปได้ทางกายภาพ ฉันกำลังโน้มตัวไปยังตัวเลือก "ผู้ขายเต็มไปด้วย" :-)
RationalGeek

@jkolhepp: ฉันสามารถคิดได้สองสามวิธีที่เป็นไปได้แต่ฉันสงสัยว่ามีวิธีใดที่จะนำไปใช้ พิจารณาความเป็นไปได้ทางไกลเพียงครั้งเดียวให้พิจารณาว่าเซิร์ฟเวอร์ที่ส่งข้อมูลเร็วกว่าตัวรับสัญญาณสามารถประมวลผลได้ดังนั้นข้อมูลจึงตกหล่นและจะต้องส่งซ้ำอีกครั้ง มันไม่น่าเป็นไปได้จริง ๆแต่เพิ่งจะเป็นไปได้
Jerry Coffin

อาจเป็นได้ก็ต่อเมื่อพวกเขาใช้โปรโตคอลเครือข่ายระดับต่ำที่อนุญาตให้ใช้กับสิ่งนั้น การใช้ "ปกติ" TCP / IP หรืออะไรก็ตามที่ป้องกันปัญหาประเภทนั้น และความเร็วในการส่งและความเร็วในการรับไม่เกี่ยวข้องกับเซิร์ฟเวอร์ "bit-ness"
RationalGeek

3
ฉันเคยเห็นปัญหาเกิดขึ้นเนื่องจากความผิดพลาดของผู้จัดจำหน่ายเช่นการเปิดเผยฟิลด์ในข้อความเครือข่ายที่มีขนาดแตกต่างกันไปขึ้นอยู่กับ "การเป็นพยาน" ของแอปพลิเคชันโดยไม่ได้ให้วิธีการค้นพบว่า
Jeffrey Hantin

6

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


เป็นความคิดที่ดี. ฉันกำลังวางแผนที่จะทำเช่นนั้น ประเด็นของคำถามนี้คือเพื่อให้แน่ใจว่าฉันไม่ได้บ้าก่อนที่จะทำเช่นนั้น :-)
RationalGeek

4

ความแตกต่างระหว่างคู่เซิร์ฟเวอร์ 32 บิตและ 64 บิตนั้นมักจะไม่มีความแตกต่าง สิ่งที่จะทำให้เกิดความแตกต่างคือendiannessของกระบวนการต่าง ๆ ซึ่งพนักงานขายอาจสับสนว่าเป็น "ความเท่าเทียมกันเล็กน้อย"


2
แม้แต่ที่ขึ้นอยู่กับโปรโตคอล (และฉันยอมรับว่าฉันไม่รู้ว่า DB ทำงานอย่างไร) ถ้าเซิร์ฟเวอร์ / ลูกค้าประกาศความเป็น endianness และอีกคนหนึ่งปรับตัวเข้ากับมันคุณก็พูดถูก แต่ประเพณีโปรโตคอลเครือข่ายที่ได้รับการ big-และในสถานการณ์เหล่านั้นสองกล่องเล็ก ๆ น้อย ๆ จะ endian ทั้งมีการแปลงวางพวกเขาที่เสียเปรียบมากขึ้นกว่า LE / พ.ศ. คู่
ijw

3

ในระยะสั้นฉันจะบอกว่าไม่มีความเท่าเทียมกันบิตไม่สำคัญ SQL Server ไม่มีโพรโทคอล 64- บิตและ 32- บิตที่แยกต่างหาก

อย่างไรก็ตามฉันขอแนะนำให้คุณสลับเซิร์ฟเวอร์เป็น 64 บิตโดยไม่คำนึงถึง SQL Server นั้นมาในแบบ 64 บิตเท่านั้นและฉันเชื่อว่า Windows Server นั้นกำลังมุ่งหน้าไปในทิศทางนั้นเช่นกัน


ฉันเห็นด้วย 64 บิตเป็นอนาคต แต่นั่นไม่ใช่ประเด็นของคำถามของฉัน ฉันกำลังถามผู้ขายว่าสมมุติว่าบิตพาริตี้เป็นข้อกำหนดที่ถูกต้องที่พวกเขาใส่กับเรา เรามีเซิร์ฟเวอร์ฟาร์มที่มีอยู่ที่เราต้องการใช้ที่ไม่ได้มีความเท่าเทียมกัน
RationalGeek

2

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

อย่างไรก็ตามการแทนค่าภายในต้องถูกแปลงระหว่างการถ่ายโอน ดังนั้นรูปแบบบางอย่างpack/unpackจะเป็นส่วนหนึ่งของมัน ฉันจะสมมติว่า protcol เครือข่ายไม่ได้กำหนดสองรูปแบบและได้รับการปรับให้เหมาะสมสำหรับเครือข่าย 64 บิตหรือค่า 32 บิต ดังนั้นอาจมีการเปลี่ยนใจเลื่อมใสและอาจวัดได้ แต่มันอาจตายไปไม่มาก


1

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

สิ่งนี้นำไปสู่คำถามสองข้อ:

  1. การแปลงนี้ทำได้เฉพาะใน 32x64
    อาจเป็นไปได้ว่าช่องสัญญาณไบนารีเป็นระบบไม่เชื่อเรื่องพระเจ้า (เพื่อให้สามารถรองรับ 32x64 และ 32x32 และ 64x64) และการแปลงจะเกิดขึ้นต่อไปในระบบ 32x32

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

มีอีกคำถามหนึ่งที่คุณต้องถามคือ:

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

เช่นถ้าเซิร์ฟเวอร์ของคุณต้องการเซิร์ฟเวอร์ 200 หน้าต่อวินาที ระบบ 32x32 สามารถส่งมอบ 202 32x64 สามารถส่ง 200 และ 64x64 สามารถส่ง 210 จากนั้นในสถานการณ์นี้มันไม่สำคัญว่าระบบที่คุณมี (พวกเขาตรงตามบาร์) แต่เป็นค่าใช้จ่ายเพิ่มเติมมูลค่า 10 หน้าต่อวินาที .

ในท้ายที่สุดแม้ว่าจะมีค่าใช้จ่ายเพิ่มเติมเล็กน้อย (ฉันสงสัย) ค่าใช้จ่ายนี้มีนัยสำคัญหรือสามารถวัดได้กับค่าใช้จ่ายอื่น ๆ ที่เกิดขึ้นจากเว็บเซิร์ฟเวอร์ ie ดูตัวอย่างสุดขีด: หากค่าใช้จ่ายในการสร้างหน้าเว็บคือ 100ms ซึ่ง 15ms เป็นเว็บเซิร์ฟเวอร์ ถ้าไม่ใช่รุ่นแพริตีบิตมีราคาแพงกว่า 33% (20ms) งัวนี้จะเพิ่มค่าใช้จ่ายในการสร้างเพจเป็น 105ms เพิ่มขึ้นเพียง 5%


นั่นคือมาร์ตินที่น่าสนใจ มีหน้าอ้างอิงสำหรับการแปลงแชนเนลไบนารีนี้หรือไม่
RationalGeek

@jkohlhepp: คุณจะต้องค้นหารายละเอียดการใช้งานเกี่ยวกับ 'SQL Server' เห็นได้ชัดว่ามันใช้โปรโตคอลกรรมสิทธิ์Data Tabular Dataฉันรู้อะไรเกี่ยวกับมัน แต่ตามหน้านี้ MS ได้เผยแพร่โปรโตคอล
Martin York
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.