¿Puede la falta de "paridad de bits" entre el servidor web y el servidor DB afectar el rendimiento?

10

Hoy tuve una reunión con un proveedor de software sobre su infraestructura recomendada para implementar una aplicación en particular. La aplicación necesita dos servidores: un servidor de aplicaciones para las páginas web del servidor (.NET, Windows) y una base de datos (SQL Server). El vendedor afirmó que estos dos servidores tenían que tener "paridad de bits". Lo que querían decir con esto es que si el servidor de la aplicación tenía 32 bits, el Servidor SQL debería tener 32 bits, o si la aplicación tiene 64 bits, el Servidor SQL tiene 64 bits. De lo contrario, el rendimiento se verá afectado negativamente.

Esto me parece ridículo. Los servidores son independientes y solo se comunican a través de una red. Los protocolos de red no tienen nada que ver con el "bit-ness" del procesador en ninguno de los servidores.

¿Estoy equivocado? ¿Hay alguna razón por la cual un desajuste en realidad podría afectar negativamente el rendimiento?

NOTA: Sé que ciertas aplicaciones pueden ejecutarse más rápido o más lento en 32 bits frente a 64 bits. Pero el vendedor decía que la falta de coincidencia entre el servidor web y el servidor de base de datos causa un problema. Esta es la declaración que estoy cuestionando.

hardware RationalGeek
fuente
En igualdad de condiciones, ¿cree que un 32 y 32 corren más rápido que un 32 y 64?
JeffO
Eso es lo que el vendedor reclamaba, sí. El rendimiento de 32,32 o 64,64 es superior a 32,64 o 64,32.
RationalGeek
Haga que configuren dos variantes del sistema. Luego, estresarlos. Compre la versión más barata que cumpla con sus requisitos.
Martin York

Respuestas:

10

Supongo que es posible que sepan alguna interacción específica entre esos dos productos que causa un problema cuando hay un desajuste (pero realmente lo dudo, pondría unas probabilidades de 10: 1 de que el vendedor está lleno).

Es posible que desee buscar en el servidor predeterminado preguntas sobre los efectos de desajustes como ese, pero dudo que encuentre mucho, porque dudo que haya algún problema real para encontrar ...

Jerry Coffin
fuente
1
+1, creo que tienes toda la razón. Puede haber consideraciones de rendimiento en cada cuadro individual, pero a través de la red, si algo es de 32 bits o de 64 bits es irrelevante.
Moo-Juice
1
¿Es posible? No puedo pensar en un escenario en el que sea una posibilidad física. También me estoy inclinando hacia la opción "vendedor lleno de eso". :-)
RationalGeek
@jkolhepp: Puedo pensar en algunas formas en que sería posible , pero dudo que alguna de ellas se aplique. Solo por una posibilidad distante, considere un servidor que envía datos más rápido de lo que el receptor puede procesarlos, de modo que los datos se descartan y deben volver a transmitirse. Es realmente poco probable, pero apenas concebible.
Jerry Coffin
Eso sería posiblemente solo si estuvieran utilizando protocolos de red de bajo nivel que permitieran ese tipo de cosas. Usar TCP / IP "normal" o lo que sea que evite ese tipo de problemas. Y la velocidad de envío frente a la velocidad de recepción no tiene nada que ver con el "bit-ness" del servidor.
RationalGeek
3
He visto problemas debido a errores del proveedor, como exponer un campo en un mensaje de red que varía en tamaño dependiendo del "bitness" de la aplicación sin proporcionar una manera de descubrir qué tamaño de campo debe enviar / esperar.
Jeffrey Hantin
6

Pide prueba. Ha hecho una declaración cuestionable, te está (mal) vendiendo cosas, ya sea que debería respaldarlo o retractarse. Ahórrate el trabajo preliminar.

ijw
fuente
Eso es una buena idea. Estoy planeando hacer eso. El objetivo de esta pregunta era asegurarme de que no estaba loco antes de hacerlo. :-)
RationalGeek
4

La diferencia entre pares de servidores de 32 bits y 64 bits probablemente no hará ninguna diferencia. Lo que marcará la diferencia es la resistencia de varios procesos, que el vendedor puede haber confundido como "paridad de bits".

Greg Buehler
fuente
2
Incluso eso depende del protocolo (y admito que no tengo idea de cómo funcionan los DB). Si el servidor / cliente declara su endianness y el otro se adapta a él, tiene toda la razón; pero, tradicionalmente, los protocolos de red han sido big-endian, y en esas circunstancias dos cajas pequeñas-endian serían tanto tiene que convertir, poniéndolos en más una desventaja que una LE / BE par.
ijw
3

En resumen, diría que no importa la paridad de bits. SQL Server no tiene un protocolo separado de 64 bits y 32 bits.

Sin embargo, recomendaría que cambie los servidores a 64 bits independientemente. SQL Server viene solo en 64 bits y creo que Windows Server también se dirige en esa dirección.

Michael Brown
fuente
Estoy de acuerdo en que 64 bits es el futuro. Pero ese no era el punto de mi pregunta. Estoy cuestionando la suposición de los vendedores de que la paridad de bits es un requisito válido que nos están imponiendo. Tenemos granjas de servidores existentes que queremos usar que no están a la par.
RationalGeek
2

Bueno, si dicho proveedor se refería estrictamente al rendimiento, podría ser cierto. Ciertamente no hay incompatibilidad entre los sistemas x86 y amd64, porque el protocolo de red debería ocultarlo.

Sin embargo, la representación interna de los valores debe transformarse durante la transferencia. Entonces alguna forma de pack/unpackserá parte de ello. Sin embargo, supondría que el protcol de red no define dos variaciones y está optimizado para una red de 64 bits o valores de 32 bits. Por lo tanto, podría haber una conversión involucrada, e incluso podría ser medible. Pero es probable que no esté muerto.

mario
fuente
1

Técnicamente, la conexión al servidor SQL suele ser un canal binario (ahora no conozco este sistema específicamente, podría ser un canal basado en texto), por lo que habrá alguna conversión en el extremo de destino cuando se recuperen los resultados de una consulta.

Esto lleva a dos preguntas:

  1. ¿Esta conversión se realiza solo en 32x64?
    Podría ser que el canal binario sea independiente del sistema (por lo que puede admitir 32x64 y 32x32 y 64x64) y la conversión sucederá de todos modos en un sistema 32x32.

  2. ¿Cuál es el costo de la conversión?
    No puedo imaginar que esto te va a afectar. El costo de la conversión binaria a binaria es pequeño y fijo.

Hay otra pregunta que debe hacer:

¿Es el costo de tener una paridad de bits más alta? Si no es así, ¿por qué meterse con los consultores? Si hay una diferencia de costo significativa, ¿cuál es la disminución real en el rendimiento y, lo más importante , la disminución en el rendimiento reduce el rendimiento del servidor web por debajo de su umbral de aceptación?

es decir, si su servidor necesita un servidor de 200 páginas por segundo. Un sistema 32x32 puede entregar 202, un 32x64 puede entregar 200 y un 64x64 puede entregar 210. Entonces, en esta situación, no importa qué sistema tenga (todos cumplen con los requisitos), pero es el costo adicional que vale las 10 páginas adicionales por segundo .

Al final, incluso si hay un pequeño costo adicional (que dudo). ¿Es este costo significativo o medible en comparación con los otros costos acumulados por el servidor web? es decir, mirando un ejemplo extremo: si el costo de construir una página es de 100 ms, de los cuales 15 ms es el servidor web. Si la versión de paridad sin bits es un 33% más cara (20 ms), este umbral solo aumenta el costo de construir una página a 105 ms, un aumento de solo el 5%.

Martin York
fuente
Eso es interesante Martin. ¿Hay alguna página de referencia para esta conversión de canal binario?
RationalGeek
@jkohlhepp: necesitará conocer los detalles de implementación sobre 'SQL Server'. Aparentemente usa el protocolo patentado Flujo de datos tabulares. No sé nada al respecto, pero según esta página, MS ha publicado el protocolo.
Martin York