Kann ein Mangel an „Bitparität“ zwischen Webserver und DB-Server die Leistung beeinträchtigen?


10

Ich hatte heute ein Treffen mit einem Softwareanbieter über die empfohlene Infrastruktur für die Bereitstellung einer bestimmten Anwendung. Die Anwendung benötigt zwei Server: einen App-Server für Server-Webseiten (.NET, Windows) und eine Datenbank (SQL Server). Der Anbieter behauptete, dass diese beiden Server "Bitparität" haben müssten. Damit meinten sie, dass wenn der App-Server 32 Bit war, der SQL Server 32 Bit sein sollte, oder wenn die App 64 Bit ist, der SQL Server 64 Bit ist. Andernfalls wird die Leistung beeinträchtigt.

Das kommt mir lächerlich vor. Die Server sind unabhängig und kommunizieren nur über ein Netzwerk. Netzwerkprotokolle haben nichts mit der "Bit-Ness" des Prozessors auf beiden Servern zu tun.

Bin ich im Unrecht? Gibt es einen Grund, warum eine Nichtübereinstimmung die Leistung negativ beeinflussen könnte?

HINWEIS: Ich weiß, dass bestimmte Apps in 32-Bit-Versionen schneller oder langsamer als in 64-Bit-Versionen ausgeführt werden können. Der Anbieter sagte jedoch, dass die Nichtübereinstimmung zwischen Webserver und DB-Server ein Problem verursacht. Dies ist die Aussage, die ich in Frage stelle.


Wenn alle anderen Dinge gleich sind, denkt er, dass ein 32 & 32 schneller läuft als ein 32 & 64?
JeffO

Das hat der Verkäufer behauptet, ja. Die Leistung von 32,32 oder 64,64 ist höher als die von 32,64 oder 64,32.
RationalGeek

Lassen Sie sie zwei Varianten des Systems einrichten. Dann testen Sie sie auf Stress. Kaufen Sie die günstigste Version, die Ihren Anforderungen entspricht.
Martin York

Antworten:


10

Ich nehme an, es ist möglich, dass sie von einer bestimmten Interaktion zwischen diesen beiden Produkten wissen, die ein Problem verursacht, wenn es zu einer Nichtübereinstimmung kommt (aber ich bezweifle es wirklich - ich würde eine Wahrscheinlichkeit von 10: 1 angeben, dass der Anbieter voll davon ist).

Vielleicht möchten Sie bei Serverfault nach Fragen zu den Auswirkungen solcher Fehlanpassungen suchen, aber ich bezweifle, dass Sie viel finden werden, da ich bezweifle, dass es ein echtes Problem gibt ...


1
+1, ich denke du hast absolut recht. Es kann durchaus Leistungsüberlegungen für jede einzelne Box geben, aber über das Netzwerk ist es irrelevant, ob etwas 32-Bit oder 64-Bit ist.
Moo-Juice

1
Ist es möglich? Ich kann mir kein Szenario vorstellen, in dem es eine physische Möglichkeit ist. Ich neige auch zur Option "Anbieter voll davon". :-)
RationalGeek

@jkolhepp: Ich kann mir ein paar Möglichkeiten vorstellen, wie es möglich wäre , aber ich bezweifle, dass eine davon zutrifft. Stellen Sie sich für eine entfernte Möglichkeit vor, dass ein Server Daten schneller sendet, als der Empfänger sie verarbeiten kann, sodass Daten gelöscht werden und erneut übertragen werden müssen. Es ist wirklich unwahrscheinlich, aber kaum vorstellbar.
Jerry Coffin

Das wäre möglicherweise nur möglich, wenn sie Netzwerkprotokolle auf niedriger Ebene verwenden würden, die dies zulassen. Die Verwendung von "normalem" TCP / IP oder was auch immer verhindert solche Probleme. Und die Geschwindigkeit des Sendens gegenüber der Geschwindigkeit des Empfangens hat nichts mit der "Bit-Ness" des Servers zu tun.
RationalGeek

3
Ich habe Probleme gesehen, die auf einen Fehler des Herstellers zurückzuführen sind, z. B. das Offenlegen eines Felds in einer Netzwerknachricht, dessen Größe je nach "Bitness" der Anwendung variiert, ohne eine Möglichkeit zu bieten, herauszufinden, welche Feldgröße Sie senden / erwarten sollten.
Jeffrey Hantin

6

Bitten Sie um Beweise. Er hat eine fragwürdige Aussage gemacht, er verkauft (falsch) Sachen, entweder sollte er sie sichern oder zurückziehen. Sparen Sie sich die Beinarbeit.


Das ist eine gute Idee. Das habe ich vor. Bei dieser Frage ging es darum sicherzustellen, dass ich nicht verrückt war, bevor ich das tat. :-)
RationalGeek

4

Der Unterschied zwischen 32-Bit- und 64-Bit-Serverpaaren macht höchstwahrscheinlich keine Unterschiede. Was einen Unterschied macht, ist die Endiannität verschiedener Prozesse, die der Verkäufer möglicherweise als "Bitparität" verwechselt hat.


2
Auch das hängt vom Protokoll ab (und ich gebe zu, ich habe keine Ahnung, wie die DBs funktionieren). Wenn der Server / Client seine Endianness erklärt und der andere sich daran anpasst, haben Sie absolut Recht. aber traditionell Netzwerkprotokolle wurden Big-Endian, und unter diesen Umständen zwei Little-Endian - Boxen würden beide zu konvertieren, so dass sie bei eher ein Nachteil als ein LE setzen / BE Paar.
ijw

3

Kurz gesagt würde ich sagen, dass keine Bitparität keine Rolle spielt. SQL Server verfügt nicht über ein separates 64-Bit- und 32-Bit-Protokoll.

Ich würde jedoch empfehlen, die Server unabhängig davon auf 64-Bit umzustellen. SQL Server ist nur in 64 Bit verfügbar, und ich glaube, dass Windows Server auch in diese Richtung geht.


Ich bin damit einverstanden, dass 64 Bit die Zukunft ist. Aber das war nicht der Punkt meiner Frage. Ich stelle die Vermutung des Anbieters in Frage, dass Bitparität eine gültige Anforderung ist, die sie an uns stellen. Wir haben vorhandene Serverfarmen, die wir verwenden möchten und die nicht in Parität sind.
RationalGeek

2

Nun, wenn sich der Anbieter ausschließlich auf die Leistung bezieht, könnte dies wahr sein. Es gibt sicherlich keine Inkompatibilität zwischen x86- und amd64-Systemen, da das Netzwerkprotokoll dies verbergen sollte.

Die interne Darstellung von Werten muss jedoch während der Übertragung transformiert werden. Also wird irgendeine Form von pack/unpackTeil davon sein. Ich würde jedoch annehmen, dass das Netzwerkprotokoll keine zwei Variationen definiert und entweder für 64-Bit-Netzwerk- oder 32-Bit-Werte optimiert ist. Es kann also zu einer Konvertierung kommen, die sogar messbar ist. Aber es ist wahrscheinlich nicht signifikant.


1

Technisch gesehen ist die Verbindung zum SQL Server normalerweise ein Binärkanal (jetzt weiß ich nicht, dass es sich bei diesem System speziell um einen textbasierten Kanal handeln kann), sodass am Zielende eine gewisse Konvertierung erfolgt, wenn die Ergebnisse einer Abfrage abgerufen werden.

Dies führt zu zwei Fragen:

  1. Wird diese Konvertierung nur auf 32x64 durchgeführt?
    Es kann sein, dass der Binärkanal systemunabhängig ist (so dass er 32x64 und 32x32 und 64x64 unterstützt) und die Konvertierung auf einem 32x32-System trotzdem erfolgt.

  2. Was kostet die Umstellung?
    Ich kann mir nicht vorstellen, dass dich das beeinflussen wird. Die Kosten für die Umwandlung von Binär zu Binär sind gering und fest.

Es gibt noch eine andere Frage, die Sie stellen müssen:

Sind die Kosten für Bitparität höher? Wenn nicht, warum dann mit den Beratern herumspielen? Wenn es einen signifikanten Kostenunterschied gibt, was ist der tatsächliche Leistungsabfall und vor allem verringert der Leistungsabfall die Leistung des Webservers unter Ihre Schwellenwertakzeptanz.

dh wenn Ihr Server 200 Seiten pro Sekunde bedienen muss. Ein 32x32-System kann 202 liefern, ein 32x64 kann 200 liefern und ein 64x64 kann 210 liefern. In dieser Situation spielt es keine Rolle, welches System Sie haben (alle erfüllen die Messlatte), aber die zusätzlichen Kosten sind die zusätzlichen 10 Seiten pro Sekunde wert .

Am Ende auch wenn es einen kleinen Aufpreis gibt (das bezweifle ich). Sind diese Kosten erheblich oder messbar gegenüber den anderen vom WebServer angefallenen Kosten? Ein extremes Beispiel: Wenn die Kosten für die Erstellung einer Seite 100 ms betragen, davon 15 ms für den WebServer. Wenn die Nicht-Bit-Paritätsversion 33% teurer ist (20 ms), erhöht diese Schwelle nur die Kosten für das Erstellen einer Seite auf 105 ms, was einer Steigerung von nur 5% entspricht.


Das ist interessant, Martin. Gibt es eine Referenzseite für diese Binärkanalkonvertierung?
RationalGeek

@jkohlhepp: Sie müssen Implementierungsdetails zu 'SQL Server' herausfinden. Anscheinend verwendet es das proprietäre Protokoll Tabular Data Stream. Ich weiß nichts darüber, aber laut dieser Seite hat MS das Protokoll veröffentlicht.
Martin York
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.