Может ли отсутствие «битовой четности» между веб-сервером и сервером БД влиять на производительность?

10

Сегодня у меня была встреча с поставщиком программного обеспечения по поводу рекомендованной им инфраструктуры для развертывания конкретного приложения. Приложению требуется два сервера: сервер приложений для серверных веб-страниц (.NET, Windows) и база данных (SQL Server). Производитель заявил, что эти два сервера должны иметь «битовую четность». Под этим они понимали, что если сервер приложений был 32-разрядным, то SQL-сервер должен быть 32-разрядным или если приложение 64-разрядное, SQL-сервер 64-разрядный. В противном случае на производительность будет оказано негативное влияние.

Это кажется смешным для меня. Серверы независимы и общаются только по сети. Сетевые протоколы не имеют ничего общего с «разрядностью» процессора на любом из серверов.

Я ошибаюсь? Есть ли причина, по которой несоответствие может негативно повлиять на производительность?

ПРИМЕЧАНИЕ. Я знаю, что некоторые приложения могут работать быстрее или медленнее в 32-битной и 64-битной версиях. Но производитель говорил, что несоответствие между веб-сервером и сервером БД вызывает проблемы. Это утверждение я ставлю под сомнение.

hardware

— RationalGeek
источник

При прочих равных условиях он думает, что 32 и 32 работают быстрее, чем 32 и 64?

— JeffO

Это то, что требовал продавец, да. Производительность 32,32 или 64,64 выше, чем 32,64 или 64,32.

— RationalGeek

Получите их, чтобы настроить два варианта системы. Затем стресс-тест их. Купите самую дешевую версию, которая соответствует вашим требованиям.

— Мартин Йорк

10

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

Возможно, вы захотите посмотреть на serverfault для вопросов о последствиях таких несоответствий, но я сомневаюсь, что вы найдете много, потому что я сомневаюсь, что есть какие-то реальные проблемы, чтобы найти

— Джерри Гроб
источник

1

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

— Moo-Juice

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». По-видимому, он использует собственный протокол Tabular Data Stream. Я ничего не знаю об этом, но согласно этой странице MS опубликовала протокол.

— Мартин Йорк