Чи може бути відсутність "бітового паритету" між веб-сервером та сервером БД впливом на продуктивність?

10

Я провів сьогодні зустріч з постачальником програмного забезпечення щодо їх рекомендованої інфраструктури для розгортання певного додатка. Програмі потрібні два сервери: сервер додатків для веб-сторінок сервера (.NET, Windows) та база даних (SQL Server). Постачальник стверджував, що ці два сервери повинні мати "бітовий паритет". Під цим вони мали на увазі те, що якщо сервер додатків був 32-бітовим, то SQL-сервер повинен бути 32-бітовим або 64-розрядним, а 64-розрядний. Інакше продуктивність негативно вплине.

Це здається мені смішним. Сервери незалежні і спілкуються лише по мережі. Мережеві протоколи не мають нічого спільного з "розрядністю" процесора на будь-якому сервері.

Я помиляюся? Чи є причина, коли невідповідність насправді може негативно вплинути на результативність?

ПРИМІТКА. Я знаю, що деякі програми можуть працювати швидше або повільніше в 32-бітному порівнянні з 64-бітовим. Але постачальник сказав, що невідповідність між веб-сервером та сервером БД викликає проблеми. Це твердження, яке я запитую.

hardware

— RationalGeek
джерело

Якщо всі інші рівні, він думає, що 32 та 32 бігають швидше, ніж 32 та 64?

— JeffO

Ось що стверджував продавець, так. Продуктивність 32,32 або 64,64 вище, ніж 32,64 або 64,32.

— RationalGeek

Запропонуйте їм встановити два варіанти системи. Потім стрес-тест на них. Купуйте найдешевшу версію, яка відповідає вашим вимогам.

— Мартін Йорк

10

Я думаю, можливо , вони знають про якусь специфічну взаємодію між цими двома продуктами, яка спричиняє проблеми, коли виникає невідповідність (але я справді сумніваюся в цьому - я б поставив приблизно 10: 1 шанси, що постачальник повний цього).

Ви можете подивитися на сервер за замовчуванням питання щодо наслідків таких невідповідностей, але я сумніваюся, що ви знайдете багато, тому що я сумніваюся, що існує якась реальна проблема ...

— Джеррі Труну
джерело

1

+1, я думаю, ти мертвий правильно. У кожному окремому вікні можуть бути міркування щодо продуктивності, але в мережі, чи є 32-бітний або 64-бітний, не має значення.

— Му-сок

1

Це можливо? Я не можу придумати один сценарій, коли це фізична можливість. Я також схиляюся до опції "повний постачальник". :-)

— RationalGeek

@jkolhepp: Я можу придумати кілька способів, як це було б можливо , але я сумніваюся, що будь-який із них застосовується. Лише для однієї віддаленої можливості, врахуйте, що сервер надсилає дані швидше, ніж одержувач може їх обробити, тому дані випадають і повинні бути повторно передані. Це насправді малоймовірно, але просто навряд чи можливо.

— Джеррі Труну

Це можливо, лише якщо вони будуть використовувати мережеві протоколи низького рівня, які дозволяють подібні речі. Використання "звичайного" TCP / IP або будь-якого іншого запобігає таким типам проблем. А швидкість надсилання та швидкість прийому не має нічого спільного з "біт-ністю" сервера.

— RationalGeek

3

Я бачив, що проблеми трапляються через пошук постачальника, наприклад, відкриття поля в мережевому повідомленні, яке змінюється за розміром залежно від "розрядності" програми, не надаючи способу дізнатися, який розмір поля ви повинні надіслати / очікувати.

— Джеффрі Хантін

6

Попросіть доказ. Він зробив сумнівну заяву, він (неправильно) продає вам речі, або він повинен їх створити, або відкликати. Збережіть собі ніжку.

— ijw
джерело

Це гарна ідея. Я планую це робити. Суть цього питання полягала в тому, щоб переконатися, що я не збожеволів до цього. :-)

— RationalGeek

4

Різниця між 32-бітовими та 64-бітовими серверними парами, швидше за все, не складе жодних відмінностей. Що буде суттєво змінити - це витривалість різних процесів, які, можливо, продавець переплутав як "бітний паритет".

— Грег Бюлер
джерело

2

Навіть це залежить від протоколу (і я визнаю, я не маю уявлення, як працюють БД). Якщо сервер / клієнт заявляє про свою небезпеку, а інший адаптується до нього, то ви абсолютно праві; але традиційно мережеві протоколи були великі зворотним порядком байтів, і в цих обставинах дві маленькі коробки-молодшому буде як треба перетворити, поміщаючи їх в більш невигідному становищі , ніж LE / BE пара.

— ijw

3

Коротше кажучи, жоден бітовий паритет не має значення. У SQL Server немає окремого 64-бітного та 32-бітного протоколу.

Однак я рекомендую вам переключити сервери на 64-бітні незалежно. SQL Server постачається лише в 64 бітах, і я вважаю, що Windows Server також рухається в цьому напрямку.

— Майкл Браун
джерело

Я згоден, 64 біт - це майбутнє. Але це не було суть мого питання. Я допитуюсь до припущення постачальників, що паритет бітів є дійсною вимогою, яку вони ставлять перед нами. У нас є існуючі ферми серверів, які ми хочемо використовувати, які не відповідають паритету.

— RationalGeek

2

Що ж, якби зазначений постачальник строго мав на увазі продуктивність, це може бути правдою. Напевно немає несумісності між системами x86 та amd64, тому що мережевий протокол повинен приховувати це.

Однак внутрішнє подання значень повинно трансформуватися під час передачі. Тож якась форма pack/unpackволі буде її частиною. Однак я б припустив, що мережевий протокол не визначає двох варіацій і оптимізований для 64-бітової мережі або 32-бітових значень. Тож може бути включено перетворення, і воно може бути навіть вимірюваним. Але це мертвий, ймовірно, не суттєвий.

— Маріо
джерело

1

Технічно з'єднання з SQL-сервером зазвичай є двійковим каналом (зараз я не знаю конкретно, що ця система може бути текстовим каналом), тому в кінцевому кінці буде здійснено деяке перетворення, коли будуть отримані результати запиту.

Це призводить до двох питань:

Це перетворення робиться лише на 32x64.
Можливо, бінарний канал є системним агностиком (так що він може підтримувати 32x64 і 32x32 і 64x64), і перетворення все одно відбудеться в системі 32x32.
Яка вартість конверсії.
Я не уявляю, що це вплине на тебе. Вартість бінарного в бінарне перетворення невелика і фіксована.

Є ще одне питання, яке потрібно задати:

Чи вище вартість паритету бітів? Якщо ні, то навіщо возитися з консультантами. Якщо є значна різниця у витратах, то яке реальне зниження продуктивності та найголовніше, чи зменшення продуктивності знижує продуктивність веб-сервера нижче Вашого порогового прийняття.

тобто якщо вам потрібно сервер на 200 сторінок в секунду. Система 32x32 може доставити 202, 32x64 може доставити 200, а 64x64 може доставити 210. Тоді в цій ситуації не має значення, яка у вас система (всі вони відповідають плані), але чи варто це коштувати додаткових 10 сторінок в секунду .

Зрештою, навіть якщо є невеликі додаткові витрати (в цьому я сумніваюся). Чи є ця вартість вагомою чи вимірюваною порівняно з іншими витратами, накопиченими WebServer. тобто, дивлячись на крайній приклад: якщо вартість створення сторінки становить 100 мс, з них 15 мс - це WebServer. Якщо небітова версія парності на 33% дорожча (20 мс), то цей підвіконня лише збільшує вартість створення сторінки до 105 мс і збільшується лише на 5%.

— Мартін Йорк
джерело

Це цікаво, Мартін. Чи є довідкова сторінка для цього бінарного перетворення каналу?

— RationalGeek

@jkohlhepp: Вам потрібно буде дізнатися деталі впровадження програми "SQL Server". Мабуть, він використовує фірмовий протокол Табличний потік даних, про це я нічого не знаю, але відповідно до цієї сторінки MS опублікував цей протокол.

— Мартін Йорк