nservicebus distributor model vs msft sql server -
we setting nservicebus in distributor/worker model , wondering if worth us.
in our initial test lab, have 2 clustered distributors , 1 worker (more workers in prod). wondering if effective leverage our high availability sql server storage , rebuild servers handle work instead of having dedicated distributors , workers. of our messages onto bus via simple .net web api service. install service on each box along endpoint dlls , have them talk sql server has more enough horsepower handle load. have load balancer available distribute messages handlers.
what of drawbacks in taking approach vs distributor model?
what has me concerned line david boike's book on nservicebus (great book btw) read...
"using sql server transport can great choice small projects on teams use sql server"
the small projects part worried about. no means small project , have pretty high volume of messages flowing through layer refactor more systems message driven.
has been down same road comparing sql server distributor , did come out?
thanks
what referring book on quote mentioned there times when have small solution, in single sql server database, , want introduce messaging around edges. sql server transport makes easy without adding bunch of additional overhead , moving parts. if keep in 1 database, can ditch distributed transactions coordinator. can useful integrating legacy system monitor changes via database triggers.
however, keep in mind (and if there's next edition, i'll sure go little more detail this) sql server transport uses broker pattern, is, communication must go through sql server becomes central point of failure , central bottleneck. default msmq transport, on other hand, follows bus architectural style, meaning it's decentralized. each endpoint can run on own, @ least until introduce additional dependencies.
andreas benchmarked new transports, , found on v4 msmq capable of 6000 sends/s , 2300 receives/s, , sqlserver on par that, on msmq per server (each server gets own throughput), sql server transport going total achievable throughput, period, , endpoints add have share it.
of course, broker-style transports (the rest of new transports in 4.0 brokers too) have advantages on msmq. biggest don't need use distributor scale out. in broker, "queue" centralized can spin additional endpoints pointing @ same input queue in competing consumers pattern.
of course in things, mileage may vary, if planning ambitious system, sql server transport may not you, @ point mired down in point option scale sql server instance.
Comments
Post a Comment