views:

203

answers:

2

Hello

(if the question is more appropriate for RackOverflow please let me know)

I've setup SQL server mirroring, using 2 SQL server 2005 standard editions. When the application is being stressed, response times increase 10-fold. I've pinpointed this to the mirror, because pausing the mirror shows acceptable response times.

What options are available for achieving better performance? Note that I'm using Standard Edition, so the excellent High Performance Mode is unavailable.

The server are in the same rack, connected to a gigabit switch.

Here's the code used to create the endpoints:

CREATE ENDPOINT [Mirroring] 
    AUTHORIZATION [sa]
    STATE=STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM RC4)
A: 

Given that the servers are in the same rack do you really need Encryption turned on? RC4 is a relatively weak algorithm, so the benefit is low. And presumably the 1 Gigabit network is private between the servers?

ENCRYPTION = DISABLED

In response to @Remus Rusanu's comment : Saying that "RC4 is a strong algorithm" is totally wrong. This is what the MSDN page has to say:

Though considerably faster than AES, RC4 is a relatively weak algorithm, while AES is a relatively strong algorithm. Therefore, we recommend that you use the AES algorithm.

Mitch Wheat
-1 (I whish I could do -100) RC4 is a strong algorithm. Stream ciphers are difficult to get right and many implementation were broken on the basis of poor key management. Now unless you know a specific attack on the RC4 key management of the mirroring endpoint protocols, I'd like you to stop spreading FUD.
Remus Rusanu
+1 for the advice to turn encryption off on the private network. I'll try that
edosoft
@Remus Rusanu: not sure where you are getting your information from, but RC4 is a relatively weak algorithm. You will note I mentioned that the servers should be connected by a private network.
Mitch Wheat
@Mitch: I reckon my comment was more of an outburst and I should had been more tempered. But here is how I know: I'm the one that wrote the network stack used by mirroring in SQL 2k5, including all the security protocols. I had to defend the algorithms and the key exchange in front of cryptographers (the kind that can sign 'I am a cryptographer...'), security experts and a penetration team. So to hear 'RC4 is weak' kinda stepped on me toe. Sry. But as a fact, RC4 is by far the most used encryption on internet today, virtually all SSL traffic is encrypted RC4.
Remus Rusanu
@Remus Rusanu: perhaps you should talk to the people responsible for the MSDN doco
Mitch Wheat
"RC4 is a stream cipher with known weaknesses. 3DES and AES are block ciphers and neither is publicly known to have been cryptanalized. 3DES has a few weak keys. AES is not known to have any. All things considered, AES-128 is likely to be the strongest among the choices. AES-128 has been around a relatively short time and probably has been subjected to less scrutiny than 3DES. (One of the more effective indicators of cipher strength is its longevity). "
Mitch Wheat
The known weaknesses of RC4 can be addressed by known mitigation, which were considered and deployed in the SSB/Mirroring protocols. I won't argue that the days of RC4 are not numbered, but saying that is 'weak' implies that it can be easily penetrated, which is not yet the case, specially not the case for the specific use in question (Mirroring).
Remus Rusanu
BTW, all above does NOT apply to the database engine RC4 symmetric key functions (Transact-SQL ENCRYPTBYKEY), that one is broken and should not be used.
Remus Rusanu
I never said "RC4 is weak", I echoed the MSDN docs that say "RC4 is relatively weak". Nonetheless, your comments are very valuable.
Mitch Wheat
+1  A: 

First you need to look at your redo queue on the mirror, how big is. This is the most likely culprit and indicates that your mirror machine is underpowered. More exactly, it cannot apply and write the log as it receives it from the principal fats enough to keep up, causing flow control to propagate back to the principal and delay transaction commits. In fact you should look at all the counters in the Mirroring Object, on both machines.

Unless you find measurements to back up suspicion on the endpoint settings, leave them as they are. The mirroring communication bandwidth is very very seldom the culprit.

Remus Rusanu
The redo queue was quite large. Further investigation lead to the conclusion that directing the mirroring traffic to another network segment solved our problems.
edosoft