Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
All other things being equal, he thinks a 32 & 32 run faster than a 32 & 64? –  JeffO Jan 26 '11 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. –  RationalGeek Jan 26 '11 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. –  Loki Astari Jan 26 '11 at 19:36

6 Answers 6

up vote 9 down vote accepted

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...

share|improve this answer
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. –  Moo-Juice Jan 26 '11 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. :-) –  RationalGeek Jan 26 '11 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. –  Jerry Coffin Jan 26 '11 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". –  RationalGeek Jan 26 '11 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. –  Jeffrey Hantin Jan 26 '11 at 19:30

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".

share|improve this answer
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. –  ijw Jan 27 '11 at 16:08

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%.

share|improve this answer
    
That is interesting Martin. Is there any reference page for this binary channel conversion? –  RationalGeek Jan 26 '11 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. –  Loki Astari Jan 26 '11 at 20:22

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.

share|improve this answer
    
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. :-) –  RationalGeek Jan 26 '11 at 19:26

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.

share|improve this answer

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.

share|improve this answer
    
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. –  RationalGeek Jan 26 '11 at 18:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.