October 6, 2005 at 8:21 am
I am considering transactional replication for synching 2 SQL systems one way. A major concern of my customer is that the interface should have very low latency between commits in 1 system and the synchronised data appearing in the second system. the target is 100ms. There is likely to be very low throughput:
0.5 transactions per second on average
3 records per transaction on average
Is transactional replication going to hack the extremely low latency requirement?
Cheers!
October 6, 2005 at 9:15 am
100 ms is a very low requirement, I'm not sure you can get that low unless you go thru some very expensive hardware level database mirroring.
or some 2 phase commit process.
Replication is very quick, but I'm not sure you'd be able to guarantee the customer that 100 ms. Even the average tps is low, there could be higher volume at different times, and the higher volume could cause you to exceeed this time frame. To get latency that low, your definatelly in a very expensive solution.
October 7, 2005 at 3:11 am
Thanks! Thats what I was thinking. What kind of latency could we expect? If it is consistantly in the 0-3 sec range I think this might be acceptable...
October 7, 2005 at 11:53 am
Your hardware and communication will have some impact, so you can't get an exact answer here. I wonder how you could measure it ? Perhaps set up a test replication, and insert some records into your publisher with a datetime field, then when the records get to the subscriber, invoke a trigger or SP that updates a 2nd datetime field, and check the differences between the 2 dates .... factoring in any differences between your servers. There's probably a better way .... anyone ?
For us, a few minutes is fine, so I haven't worried too much.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply