Le manque de «parité de bits» entre le serveur Web et le serveur DB peut-il affecter les performances?

10

J'ai eu une réunion avec un fournisseur de logiciels aujourd'hui au sujet de leur infrastructure recommandée pour déployer une application particulière. L'application a besoin de deux serveurs: un serveur d'applications pour les pages Web du serveur (.NET, Windows) et une base de données (SQL Server). Le vendeur a affirmé que ces deux serveurs devaient avoir une "parité de bits". Ce qu'ils voulaient dire par là, c'est que si le serveur d'applications était de 32 bits, SQL Server devrait être de 32 bits, ou si l'application est de 64 bits, SQL Server est de 64 bits. Sinon, les performances seront affectées négativement.

Cela me semble ridicule. Les serveurs sont indépendants et ne communiquent que sur un réseau. Les protocoles réseau n'ont rien à voir avec le "bit-ness" du processeur sur l'un ou l'autre des serveurs.

Suis-je dans l'erreur? Y a-t-il une raison pour laquelle une non-concordance pourrait avoir un impact négatif sur les performances?

REMARQUE: je sais que certaines applications peuvent s'exécuter plus rapidement ou plus lentement en 32 bits contre 64 bits. Mais le vendeur disait que l' inadéquation entre le serveur Web et le serveur de base de données pose problème. Voici la déclaration que je conteste.

hardware RationalGeek
la source
Toutes choses étant égales par ailleurs, il pense qu'un 32 & 32 tourne plus vite qu'un 32 & 64?
JeffO
C'est ce que le vendeur prétendait, oui. Les performances de 32,32 ou 64,64 sont supérieures à 32,64 ou 64,32.
RationalGeek
Demandez-leur de configurer deux variantes du système. Ensuite, testez-les. Achetez la version la moins chère qui répond à vos besoins.
Martin York

Réponses:

10

Je suppose qu'il est possible qu'ils connaissent une interaction spécifique entre ces deux produits qui cause un problème en cas de non-concordance (mais j'en doute vraiment - je mettrais environ 10: 1 pour que le vendeur en soit plein).

Vous voudrez peut-être chercher sur serverfault des questions sur les effets de disparités comme ça, mais je doute que vous en trouverez beaucoup, car je doute qu'il y ait un vrai problème à trouver ...

Jerry Coffin
la source
1
+1, je pense que vous avez raison. Il peut y avoir des considérations de performances sur chaque boîtier individuel, mais sur le réseau, le fait que quelque chose soit 32 bits ou 64 bits n'est pas pertinent.
Moo-Juice du
1
C'est possible? Je ne peux pas penser à un scénario où c'est une possibilité physique. Je penche également vers l'option "fournisseur plein de celui-ci". :-)
RationalGeek
@jkolhepp: Je peux penser à plusieurs façons possibles , mais je doute que l'une d'entre elles s'applique. Pour une seule possibilité éloignée, considérez un serveur envoyant des données plus rapidement que le récepteur ne peut les traiter, de sorte que les données soient supprimées et doivent être retransmises. C'est vraiment peu probable, mais à peine concevable.
Jerry Coffin le
Ce ne serait probablement que s'ils utilisaient des protocoles réseau de bas niveau qui permettaient ce genre de chose. L'utilisation de TCP / IP «normal» ou de tout ce qui empêche ces types de problèmes. Et la vitesse d'envoi par rapport à la vitesse de réception n'a rien à voir avec le "bit-ness" du serveur.
RationalGeek
3
J'ai vu des problèmes se produire en raison de la bêtise du fournisseur, tels que l'exposition d'un champ dans un message réseau dont la taille varie en fonction du "témoin" de l'application sans fournir un moyen de découvrir la taille de champ que vous devez envoyer / attendre.
Jeffrey Hantin,
6

Demandez une preuve. Il a fait une déclaration douteuse, il (vous) vend mal, soit il devrait le sauvegarder, soit le retirer. Gardez-vous les jambes.

ijw
la source
C'est une bonne idée. Je prévois de le faire. Le but de cette question était de m'assurer que je n'étais pas fou avant de le faire. :-)
RationalGeek
4

La différence entre les paires de serveurs 32 bits et 64 bits ne fera vraisemblablement aucune différence. Ce qui fera la différence, c'est l' endianité de divers processus, que le vendeur peut avoir confondus avec la "parité des bits".

Greg Buehler
la source
2
Même cela dépend du protocole (et j'avoue que je n'ai aucune idée du fonctionnement des DB). Si le serveur / client déclare son endianité et que l'autre s'y adapte, alors vous avez absolument raison; mais traditionnellement, les protocoles réseau ont été big-endian, et dans ces circonstances, deux boîtes little-endian devraient toutes deux être converties, ce qui les désavantage davantage qu'une paire LE / BE.
ijw
3

En bref, je dirais que la parité des bits n'a pas d'importance. SQL Server ne dispose pas d'un protocole distinct 64 bits et 32 ​​bits.

Cependant, je recommanderais que vous commutiez les serveurs sur 64 bits malgré tout. SQL Server n'est disponible qu'en 64 bits et je pense que Windows Server se dirige également dans cette direction.

Michael Brown
la source
Je suis d'accord 64 bits est l'avenir. Mais ce n'était pas le but de ma question. Je remets en question la supposition des fournisseurs selon laquelle la parité des bits est une exigence valable qu'ils nous imposent. Nous avons des batteries de serveurs existantes que nous voulons utiliser qui ne sont pas en parité.
RationalGeek
2

Eh bien, si ledit fournisseur faisait strictement référence aux performances, il pourrait y avoir une part de vérité. Il n'y a certainement aucune incompatibilité entre les systèmes x86 et amd64, car le protocole réseau devrait cacher cela.

Cependant la représentation interne des valeurs doit être transformée lors du transfert. Donc, une certaine forme en pack/unpackfera partie. Je suppose cependant que le protocole réseau ne définit pas deux variantes et est optimisé pour un réseau 64 bits ou des valeurs 32 bits. Il pourrait donc y avoir conversion, et elle pourrait même être mesurable. Mais c'est mort probablement non significatif.

mario
la source
1

Techniquement, la connexion au serveur SQL est généralement un canal binaire (maintenant je ne connais pas spécifiquement ce système, il pourrait s'agir d'un canal basé sur du texte), il y aura donc une conversion à l'extrémité de destination lorsque les résultats d'une requête seront récupérés.

Cela conduit à deux questions:

  1. Cette conversion est-elle effectuée uniquement sur 32x64
    Il se peut que le canal binaire soit indépendant du système (afin qu'il puisse prendre en charge 32x64 et 32x32 et 64x64) et la conversion se fera de toute façon sur un système 32x32.

  2. Quel est le coût de la conversion.
    Je ne peux pas imaginer que cela va vous affecter. Le coût de la conversion binaire en binaire est petit et fixe.

Il y a une autre question que vous devez vous poser:

Le coût de la parité des bits est-il plus élevé? Sinon, pourquoi jouer avec les consultants. S'il y a une différence de coût significative, quelle est la diminution réelle des performances et, surtout, la diminution des performances réduit les performances du serveur Web en dessous de votre seuil d'acceptation.

c'est à dire si votre serveur a besoin de serveur 200 pages par seconde. Un système 32x32 peut fournir 202, un 32x64 peut fournir 200 et un 64x64 peut fournir 210. Dans ce cas, peu importe le système que vous avez (ils respectent tous la barre), mais le coût supplémentaire vaut-il les 10 pages supplémentaires par seconde? .

Au final même s'il y a un petit surcoût (ça j'en doute). Ce coût est-il significatif ou mesurable par rapport aux autres coûts supportés par le WebServer? c'est-à-dire en regardant un exemple extrême: si le coût de construction d'une page est de 100 ms dont 15 ms pour le WebServer. Si la version à parité non binaire est 33% plus chère (20 ms), ce seuil augmente le coût de construction d'une page à 105 ms, soit une augmentation de 5% seulement.

Martin York
la source
C'est intéressant Martin. Existe-t-il une page de référence pour cette conversion de canal binaire?
RationalGeek
@jkohlhepp: vous devrez trouver les détails d'implémentation de 'SQL Server'. Apparemment, il utilise le protocole propriétaire Tabular Data Stream, je n'en sais rien, mais selon cette page, MS a publié le protocole.
Martin York