A falta de "paridade de bits" entre o servidor Web e o servidor DB afeta o desempenho?

10

Hoje tive uma reunião com um fornecedor de software sobre a infraestrutura recomendada para implantar um aplicativo específico. O aplicativo precisa de dois servidores: um servidor de aplicativos para páginas da web do servidor (.NET, Windows) e um banco de dados (SQL Server). O fornecedor alegou que esses dois servidores tinham que ter "paridade de bits". O que eles queriam dizer com isso é que, se o servidor de aplicativos tiver 32 bits, o SQL Server deverá ter 32 bits ou se o aplicativo for 64 bits, o SQL Server será 64 bits. Caso contrário, o desempenho será impactado negativamente.

Isso me parece ridículo. Os servidores são independentes e se comunicam apenas por uma rede. Os protocolos de rede não têm nada a ver com o "bit-ness" do processador em qualquer servidor.

Estou errado? Existe uma razão pela qual uma incompatibilidade realmente possa afetar negativamente o desempenho?

NOTA: Eu sei que certos aplicativos podem ser executados mais rápido ou mais devagar em 32 bits vs. 64 bits. Mas o fornecedor estava dizendo que a incompatibilidade entre servidor da Web e servidor de banco de dados causa um problema. Esta é a afirmação que estou questionando.

hardware

— RationalGeek
fonte

Todas as outras coisas sendo iguais, ele acha que 32 e 32 rodam mais rápido que 32 e 64?

— Jeffo

Isso é o que o fornecedor estava reivindicando, sim. O desempenho de 32,32 ou 64,64 é superior a 32,64 ou 64,32.

— RationalGeek

Faça com que eles configurem duas variantes do sistema. Em seguida, teste-os. Compre a versão mais barata que atenda às suas necessidades.

— Martin Iorque

10

Suponho que seja possível que eles saibam de alguma interação específica entre esses dois produtos que causa um problema quando há uma incompatibilidade (mas eu realmente duvido - eu colocaria chances de 10: 1 de que o fornecedor está cheio disso).

Você pode procurar no serverfault por perguntas sobre efeitos de incompatibilidades como essa, mas duvido que você encontre muito, porque duvido que exista algum problema real a ser encontrado ...

— Jerry Coffin
fonte

11

+1, acho que você está absolutamente certo. Pode haver considerações de desempenho em cada caixa individual, mas na rede, se algo é 32 bits ou 64 bits, é irrelevante.

— Moo-Juice

11

É possível? Não consigo pensar em um cenário em que seja uma possibilidade física. Também estou me inclinando para a opção "fornecedor cheio disso". :-)

— RationalGeek

@jkolhepp: Posso pensar em algumas maneiras possíveis , mas duvido que alguma delas se aplique. Apenas para uma possibilidade distante, considere um servidor enviando dados mais rapidamente do que o receptor pode processá-los, para que os dados sejam descartados e precisem ser retransmitidos. É realmente improvável, mas apenas concebível.

— Jerry Coffin

Isso seria possível apenas se eles estivessem usando protocolos de rede de baixo nível que permitissem esse tipo de coisa. O uso de TCP / IP "normal" ou qualquer outra coisa impede esses tipos de problemas. E a velocidade de envio versus a velocidade de recebimento não tem nada a ver com a "mordidez" do servidor.

— RationalGeek

3

Vi problemas acontecerem devido a informações enganosas do fornecedor, como expor um campo em uma mensagem de rede que varia em tamanho, dependendo da "testemunha" do aplicativo, sem fornecer uma maneira de descobrir qual tamanho de campo você deve enviar / esperar.

— Jeffrey Hantin

6

Peça prova. Ele fez uma declaração questionável, está (mis-) vendendo coisas para você, ou ele deve fazer backup ou retraí-lo. Salve-se o trabalho braçal.

— ijw
fonte

Isso é uma boa ideia. Estou pensando em fazer isso. O objetivo desta pergunta era garantir que eu não estivesse louco antes de fazê-lo. :-)

— RationalGeek

4

A diferença entre pares de servidores de 32 bits e 64 bits provavelmente não fará nenhuma diferença. O que fará a diferença é a continuidade de vários processos, que o vendedor pode ter confundido como sendo "paridade de bits".

— Greg Buehler
fonte

2

Até isso depende do protocolo (e admito que não faço ideia de como os DB funcionam). Se o servidor / cliente declara sua existência e o outro se adapta a ele, você está absolutamente certo; mas tradicionalmente protocolos de rede foram big-endian, e, nessas circunstâncias, duas caixas de pequenos-endian que tanto tem que converter, colocando-os em mais uma desvantagem do que uma LE / BE par.

— IJW

3

Em resumo, eu diria que nenhuma paridade de bits não importa. O SQL Server não possui um protocolo de 64 e 32 bits separado.

No entanto, eu recomendaria que você alternasse os servidores para 64 bits, independentemente. O SQL Server vem apenas em 64 bits e acredito que o Windows Server também esteja indo nessa direção.

— Michael Brown
fonte

Eu concordo que 64 bits é o futuro. Mas esse não era o ponto da minha pergunta. Estou questionando a suposição dos fornecedores de que a paridade de bits é um requisito válido que eles estão colocando em nós. Temos farms de servidores existentes que queremos usar que não estão em paridade.

— RationalGeek

2

Bem, se esse fornecedor se referir estritamente ao desempenho, pode haver alguma verdade nisso. Certamente não há incompatibilidade entre os sistemas x86 e amd64, porque o protocolo de rede deve esconder isso.

No entanto, a representação interna dos valores deve ser transformada durante a transferência. Então, alguma forma de pack/unpackfazer parte dela. No entanto, eu assumiria que o protocolo de rede não define duas variações e é otimizado para valores de rede ou de 32 bits de 64 bits. Portanto, pode haver conversão envolvida e pode até ser mensurável. Mas é provável que não seja significativo.

— mario
fonte

1

Tecnicamente, a conexão com o servidor SQL geralmente é um canal binário (agora não conheço esse sistema especificamente, poderia ser um canal baseado em texto), portanto haverá alguma conversão no final do destino quando os resultados de uma consulta forem recuperados.

Isso leva a duas perguntas:

Essa conversão é feita apenas em 32x64
Pode ser que o canal binário seja independente do sistema (para que possa suportar 32x64 e 32x32 e 64x64) e a conversão ocorrerá de qualquer maneira em um sistema 32x32.
Qual é o custo da conversão.
Não consigo imaginar que isso vai afetá-lo. O custo da conversão de binário para binário é pequeno e fixo.

Há uma outra pergunta que você precisa fazer:

O custo da paridade de bits é maior? Se não, então por que mexer com os consultores. Se houver uma diferença de custo significativa, qual é a redução real no desempenho e o mais importante é que a diminuição no desempenho diminui o desempenho do servidor da Web abaixo da sua aceitação de limite.

ou seja, se o seu servidor precisar 200 páginas por segundo. Um sistema 32x32 pode fornecer 202, um 32x64 pode fornecer 200 e um 64x64 pode fornecer 210. Então, nessa situação, não importa qual sistema você possui (todos eles atendem aos padrões), mas é o custo extra que vale 10 páginas extras por segundo .

No final, mesmo que haja um pequeno custo extra (que eu duvido). Esse custo é significativo ou mensurável em relação aos outros custos acumulados pelo servidor da Web. Ou seja, olhando para um exemplo extremo: se o custo de criação de uma página for 100ms, dos quais 15ms é o servidor da Web. Se a versão sem paridade de bits for 33% mais cara (20ms), esse peitoril apenas aumentará o custo de criação de uma página para 105ms, um aumento em apenas 5%.

— Martin York
fonte

Isso é interessante, Martin. Existe alguma página de referência para esta conversão de canal binário?

— RationalGeek

@jkohlhepp: Você precisará descobrir detalhes de implementação sobre o 'SQL Server'. Aparentemente, ele usa o protocolo proprietário Tabular Data Stream. Não sei nada sobre isso, mas de acordo com esta página a MS publicou o protocolo.

— Martin York