Czy brak „parzystości bitowej” między serwerem WWW a serwerem DB może wpłynąć na wydajność?

10

Dzisiaj spotkałem się z dostawcą oprogramowania na temat ich zalecanej infrastruktury do wdrażania konkretnej aplikacji. Aplikacja potrzebuje dwóch serwerów: serwera aplikacji dla stron internetowych serwera (.NET, Windows) oraz bazy danych (SQL Server). Sprzedawca twierdził, że te dwa serwery musiały mieć „bit parzystości”. Rozumieli przez to, że jeśli serwer aplikacji był 32-bitowy, SQL Server powinien być 32-bitowy lub jeśli aplikacja ma 64-bitowy, to SQL Server jest 64-bitowy. W przeciwnym razie pogorszy się wydajność.

To wydaje mi się śmieszne. Serwery są niezależne i komunikują się tylko przez sieć. Protokoły sieciowe nie mają nic wspólnego z „bitowością” procesora na obu serwerach.

Czy się mylę? Czy istnieje powód, dla którego niedopasowanie może negatywnie wpłynąć na wydajność?

UWAGA: Wiem, że niektóre aplikacje mogą działać szybciej lub wolniej w wersji 32-bitowej w porównaniu do 64-bitowej. Ale sprzedawca powiedział, że niedopasowanie między serwerem WWW a serwerem DB powoduje problem. To stwierdzenie, które kwestionuję.

hardware

— RationalGeek
źródło

Wszystkie inne rzeczy są równe, uważa, że 32 i 32 działają szybciej niż 32 i 64?

— JeffO

Tak twierdził sprzedawca, tak. Wydajność 32, 32 lub 64, 64 jest wyższa niż 32, 64 lub 64, 32.

— RationalGeek

Poproś ich o skonfigurowanie dwóch wariantów systemu. Następnie przetestuj je. Kup najtańszą wersję spełniającą Twoje wymagania.

— Martin York,

10

Przypuszczam, że możliwe jest , że znają jakąś konkretną interakcję między tymi dwoma produktami, która powoduje problem w przypadku niedopasowania (ale naprawdę w to wątpię - postawiłbym około 10: 1, że sprzedawca jest tego pełen).

Być może będziesz chciał sprawdzić na serwerze, czy masz pytania dotyczące skutków takich niedopasowań, ale wątpię, czy znajdziesz wiele, ponieważ wątpię, czy istnieje jakiś prawdziwy problem ...

— Jerry Coffin
źródło

1

+1, myślę, że masz rację. Na każdym pojedynczym urządzeniu mogą występować względy wydajności, ale w sieci nie ma znaczenia, czy coś jest 32-bitowe, czy 64-bitowe.

— Moo-Juice

1

Czy to możliwe? Nie mogę wymyślić jednego scenariusza, w którym jest to fizyczna możliwość. Skłaniam się również ku opcji „pełny dostawca”. :-)

— RationalGeek

@jkolhepp: Mogę wymyślić kilka sposobów, które byłyby możliwe , ale wątpię, by którykolwiek z nich miał zastosowanie. Tylko dla jednej odległej możliwości rozważ serwer wysyłający dane szybciej niż odbiorca może je przetworzyć, aby dane zostały upuszczone i musiały zostać ponownie przesłane. To naprawdę mało prawdopodobne, ale ledwo możliwe.

— Jerry Coffin

Byłoby to możliwe tylko wtedy, gdyby korzystali z niskopoziomowych protokołów sieciowych, które zezwalały na takie rzeczy. Korzystanie z „normalnego” protokołu TCP / IP lub cokolwiek innego zapobiega tego typu problemom. Szybkość wysyłania a szybkość odbierania nie ma nic wspólnego z „bitowością” serwera.

— RationalGeek

3

Widziałem problemy występujące z powodu wygłupiania się przez dostawcę, takie jak wyświetlanie pola w komunikacie sieciowym, które różni się rozmiarem w zależności od „bitowości” aplikacji, bez możliwości sprawdzenia, jaki rozmiar pola należy wysłać / oczekiwać.

— Jeffrey Hantin

6

Poproś o dowód. Złożył wątpliwe oświadczenie, że (źle) sprzedaje ci rzeczy, albo powinien to zrobić, albo cofnąć. Oszczędź sobie pracy nóg.

— ijw
źródło

To dobry pomysł. Planuję to zrobić. Celem tego pytania było upewnienie się, że nie oszalałem, zanim to zrobiłem. :-)

— RationalGeek

4

Różnica między 32-bitowymi i 64-bitowymi parami serwerów najprawdopodobniej nie spowoduje żadnych różnic. To, co zrobi różnicę, to endianizm różnych procesów, które sprzedawca mógł pomylić jako „bit parzystości”.

— Greg Buehler
źródło

2

Nawet to zależy od protokołu (i przyznaję, że nie mam pojęcia, jak działają te DB). Jeśli serwer / klient deklaruje swoją endianizm, a drugi dostosowuje się do niego, to masz całkowitą rację; ale tradycyjnie protokoły sieciowe zostały big-endian, aw tych okolicznościach dwa małe pudełka-endian by obie mają do konwersji, umieszczając je w bardziej niekorzystnej sytuacji niż LE / BE pair.

— ijw 27.01.11

3

Krótko mówiąc, powiedziałbym, że żadna parzystość bitowa nie ma znaczenia. SQL Server nie ma osobnego protokołu 64-bitowego i 32-bitowego.

Jednak zalecam zmianę serwerów na 64-bitową niezależnie. SQL Server jest dostępny tylko w wersji 64-bitowej i uważam, że Windows Server również zmierza w tym kierunku.

— Michael Brown
źródło

Zgadzam się, 64-bitowa przyszłość. Ale nie o to chodziło w moim pytaniu. Kwestionuję przypuszczenie dostawców, że parzystość bitów jest ważnym wymogiem, który nas nakładają. Mamy istniejące farmy serwerów, z których chcemy korzystać, a które nie są w parze.

— RationalGeek

2

Cóż, jeśli wspomniany sprzedawca ściśle odnosi się do wydajności, może być w tym trochę prawdy. Z pewnością nie ma niezgodności między systemami x86 i amd64, ponieważ protokół sieciowy powinien to ukryć.

Jednak wewnętrzna reprezentacja wartości musi zostać przekształcona podczas przesyłania. Więc jakaś forma pack/unpackbędzie tego częścią. Zakładam jednak, że protokół sieciowy nie definiuje dwóch odmian i jest zoptymalizowany dla 64-bitowej sieci lub 32-bitowej wartości. Może więc wystąpić konwersja, a może być nawet mierzalna. Ale to prawdopodobnie nie jest znaczące.

— Mario
źródło

1

Technicznie połączenie z serwerem SQL jest zwykle kanałem binarnym (teraz nie znam tego systemu, może to być kanał tekstowy), więc po pobraniu wyników zapytania nastąpi konwersja na końcu docelowym.

To prowadzi do dwóch pytań:

Czy ta konwersja jest wykonywana tylko na 32x64
Może być tak, że kanał binarny jest niezależny od systemu (dzięki czemu może obsługiwać 32x64 oraz 32x32 i 64x64), a konwersja nastąpi mimo to w systemie 32x32.
Jaki jest koszt konwersji.
Nie wyobrażam sobie, żeby to miało na ciebie wpływ. Koszt konwersji binarnej na binarną jest niewielki i stały.

Jest jeszcze jedno pytanie, które musisz zadać:

Czy koszt posiadania parzystości bitów jest wyższy? Jeśli nie, to po co zadzierać z konsultantami. Jeśli istnieje znacząca różnica kosztów, jaki jest rzeczywisty spadek wydajności, a co najważniejsze , spadek wydajności obniża wydajność serwera internetowego poniżej akceptowalnego progu.

tzn. jeśli serwer wymaga serwera 200 stron na sekundę. System 32x32 może dostarczyć 202, 32x64 może dostarczyć 200, a 64x64 może dostarczyć 210. W tej sytuacji nie ma znaczenia, jaki system posiadasz (wszystkie spełniają kryteria), ale to dodatkowy koszt warty dodatkowych 10 stron na sekundę .

W końcu nawet jeśli wiąże się to z niewielkimi dodatkowymi kosztami (wątpię). Czy ten koszt jest znaczący czy mierzalny w porównaniu z innymi kosztami naliczonymi przez WebServer. tzn. Patrząc na skrajny przykład: jeśli koszt budowy strony wynosi 100ms, z czego 15ms to WebServer. Jeśli wersja z bitową parzystością jest o 33% droższa (20 ms), to parapet podnosi jedynie koszt budowy strony do 105 ms, a wzrost tylko o 5%.

— Martin York
źródło

To interesujące Martin. Czy jest jakaś strona referencyjna dla tej konwersji kanału binarnego?

— RationalGeek

@jkohlhepp: Musisz znaleźć szczegółowe informacje na temat implementacji programu „SQL Server”. Najwyraźniej używa zastrzeżonego protokołu Tabularny strumień danych Nie wiem o tym nic, ale zgodnie z tą stroną MS opublikowało protokół.

— Martin York,