10

I had a meeting with a software vendor today about their recommended infrastructure for deploying a particular application. The application needs two servers: an app server for server web pages (.NET, Windows), and a database (SQL Server). The vendor claimed that these two servers had to have "bit parity". What they meant by this is that if the app server was 32 bit the SQL Server should be 32 bit, or if the app is 64 bit the SQL Server is 64 bit. Otherwise performance will be negatively impacted.

This seems ludicrous to me. The servers are independent and only communicate over a network. Network protocols have nothing to do with the "bit-ness" of the processor on either server.

Am I in the wrong? Is there a reason where a mismatch actually could negatively impact performance?

NOTE: I know that certain apps might run faster or slower in 32 bit vs. 64 bit. But the vendor was saying that the mismatch between web server and DB server causes a problem. This is the statement I'm questioning.

Improve this question
3
  • All other things being equal, he thinks a 32 & 32 run faster than a 32 & 64? Commented Jan 26, 2011 at 18:40
  • That is what the vendor was claiming, yes. Performance of 32,32 or 64,64 is higher than 32,64 or 64,32. Commented Jan 26, 2011 at 19:15
  • Get them to set up two variants of the system. Then stress test them. Buy the cheapest version that meets your requirements. Commented Jan 26, 2011 at 19:36

6 Answers 6

Reset to default
10

I suppose it's possible that they know of some specific interaction between those two products that causes a problem when there's a mismatch (but I really doubt it -- I'd put about 10:1 odds that the vendor's full of it).

You might want to look on serverfault for questions about effects of mismatches like that, but I doubt you'll find much, because I doubt there's any real problem to find...

Improve this answer
7
  • 1
    +1, I think you're dead right. There may well be performance considerations on each individual box, but over the network, whether something is 32 bit or 64 bit is irrelevant. Commented Jan 26, 2011 at 18:00
  • 1
    Is it possible? I can't think of one scenario where it is a physical possibility. I am also leaning toward the "vendor full of it" option. :-) Commented Jan 26, 2011 at 18:00
  • @jkolhepp: I can think of a few ways it would be possible, but I doubt any of them applies. Just for one distant possibility, consider a server sending data faster than the receiver can process it, so data gets dropped and has to be re-transmitted. It's really unlikely, but just barely conceivable. Commented Jan 26, 2011 at 18:02
  • That would be possibly only if they were using low-level network protocols that allowed for that kind of thing. Using "normal" TCP/IP or whatever prevents those types of issues. And speed of sending vs. speed of receiving has nothing to do with server "bit-ness". Commented Jan 26, 2011 at 18:08
  • 3
    I've seen issues happen due to vendor goof, such as exposing a field in a network message that varies in size depending on the "bitness" of the application without providing a way to discover what field size you should send/expect. Commented Jan 26, 2011 at 19:30
6

Ask for proof. He's made a questionable statement, he's (mis-)selling you stuff, either he should back it up or retract it. Save yourself the legwork.

Improve this answer
1
  • That is a good idea. I am planning on doing that. The point of this question was to make sure I wasn't crazy before I did so. :-) Commented Jan 26, 2011 at 19:26
4

The difference between 32bit and 64bit server pairs will in most likelihood not make any differences. What will make a difference is the endianness of various processes, which the sales person may have confused as being "bit parity".

Improve this answer
1
  • 2
    Even that depends on the protocol (and I admit I have no idea how the DB ones work). If the server / client declares its endianness and the other one adapts to it, then you're absolutely right; but traditionally network protocols have been big-endian, and in those circumstances two little-endian boxes would both have to convert, putting them at more of a disadvantage than a LE/BE pair. Commented Jan 27, 2011 at 16:08
3

In short I would say no bit-parity doesn't matter. SQL Server doesn't have a separate 64-bit and 32-bit protocol.

However, I would recommend that you switch servers over to 64 bit regardless. SQL Server comes in 64 bit only and I believe that Windows Server is heading in that direction as well.

Improve this answer
1
  • I agree 64 bit is the future. But that wasn't the point of my question. I'm questioning the vendors supposition that bit parity is a valid requirement they are putting on us. We have existing server farms that we want to use that aren't in parity. Commented Jan 26, 2011 at 18:07
2

Well, if said vendor was strictly referring to performance, there might be some truth to it. There's certainly no incompatibility between x86 and amd64 systems, because the network protocol should hide that away.

However the internal representation of values must be transformed during transfer. So some form of pack/unpack will be part of it. I would however assume that the network protcol does not define two variations, and is either optimized for 64 bit network or 32 bit values. So there might be conversion involved, and and it might even be measurable. But it's dead likely not significant.

Improve this answer
1

Technically the connection to the SQL server is usually a binary channel (Now I don't know this system specifically it could be a text based channel) so there will be some conversion at the destination end when the results of a query are retrieved.

This leads to two questions:

  1. Is this conversion done only on 32x64
    It could be that binary channel is system agnostic (so that it can support 32x64 and 32x32 and 64x64) and the conversion will happen anyway on a 32x32 system.

  2. What is the cost of the conversion.
    I can't imagine this is going to affect you. The cost of binary to binary conversion is small and fixed.

There is one other question you need to ask:

Is the cost of having bit parity higher? If not then why mess with the consultants. If there is a significant cost difference then what is the real decrease in performance and most importantly does the decrease in performance lower the performance of the Web server below your threshold acceptance.

i.e. If you server needs to server 200 pages a second. A 32x32 system can deliver 202 a 32x64 can deliver 200 and a 64x64 can deliver 210. Then in this situation it does not matter what system you have (they all meet the bar), but is the extra cost worth the extra 10 pages a second.

In the end even if there is a small extra cost (that I doubt). Is this cost significant or measurable against the other costs accrued by the WebServer. i.e. Looking at an extreme example: if the cost of building a page is 100ms of which 15ms is the WebServer. If the non bit parity version is 33% more expensive (20ms) then this sill only raises the cost of building a page to 105ms an increase in only 5%.

Improve this answer
2
  • That is interesting Martin. Is there any reference page for this binary channel conversion? Commented Jan 26, 2011 at 19:38
  • @jkohlhepp: You will need to find out implementation details about 'SQL Server'. Apparently it uses the proprietary protocol Tabular Data Stream I know nothing about it but according to this page MS has published the protocol. Commented Jan 26, 2011 at 20:22

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.