@max_concurrent_merge

I have a merge publication (dynamically filtered). Subscriptions are
all anonymous (all run at the subscriber) and run continuously.
What effect does the publication option @.max_concurrent_merge have on
a replication topology such as this? Also known as the "Publication
Properties | Subscriptions tab | "Limit the number of concurrent merge
processes to the following" setting . . .
I noticed in a test environment when I set it to 1 my 2 anonymous
subscribers are still able to connect and reach "no data to be
merged". . . does setting this physically limit the number of "merge
activity" or the number of "merge agent connections" or something
else? I believe my testing shows it doens't limit the connections, but
maybe it does something w/ the "merge activity" under the hood?
Any help is greatly appreciated . . .
Matt
It limits the number of simultaneous merge agents that can run. The default
for this is 10, so if you have 20 subscribers running continuously, only 10
of them would be running simultaneously and the rest would be queued.
For 2 subscribers you should not have to worry about it.
Please refer to this link for a more indepth discussion of this.
http://www.microsoft.com/technet/pro.../mergperf.mspx
"Matt" <la_la_looey@.yahoo.com> wrote in message
news:a0313d3.0404210946.4e767ee9@.posting.google.co m...
> I have a merge publication (dynamically filtered). Subscriptions are
> all anonymous (all run at the subscriber) and run continuously.
> What effect does the publication option @.max_concurrent_merge have on
> a replication topology such as this? Also known as the "Publication
> Properties | Subscriptions tab | "Limit the number of concurrent merge
> processes to the following" setting . . .
> I noticed in a test environment when I set it to 1 my 2 anonymous
> subscribers are still able to connect and reach "no data to be
> merged". . . does setting this physically limit the number of "merge
> activity" or the number of "merge agent connections" or something
> else? I believe my testing shows it doens't limit the connections, but
> maybe it does something w/ the "merge activity" under the hood?
> Any help is greatly appreciated . . .
> Matt
|||2 subscribers was my test lab . . . I actually have over 100.
I believe after extended testing, I see this setting simply controls
the number of connections . . . so, if you have your agent set to run
continuously, other agents would "starve."
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<#HF4BTBKEHA.2556@.TK2MSFTNGP11.phx.gbl>...[vbcol=seagreen]
> It limits the number of simultaneous merge agents that can run. The default
> for this is 10, so if you have 20 subscribers running continuously, only 10
> of them would be running simultaneously and the rest would be queued.
> For 2 subscribers you should not have to worry about it.
> Please refer to this link for a more indepth discussion of this.
> http://www.microsoft.com/technet/pro.../mergperf.mspx
>
> "Matt" <la_la_looey@.yahoo.com> wrote in message
> news:a0313d3.0404210946.4e767ee9@.posting.google.co m...
|||not so, they are queued until the others finished. sort of like a round
robin. Check out the link for more info.
"Matt" <la_la_looey@.yahoo.com> wrote in message
news:a0313d3.0404220441.15777f5c@.posting.google.co m...
> 2 subscribers was my test lab . . . I actually have over 100.
> I believe after extended testing, I see this setting simply controls
> the number of connections . . . so, if you have your agent set to run
> continuously, other agents would "starve."
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
news:<#HF4BTBKEHA.2556@.TK2MSFTNGP11.phx.gbl>...[vbcol=seagreen]
default[vbcol=seagreen]
10[vbcol=seagreen]
http://www.microsoft.com/technet/pro.../mergperf.mspx[vbcol=seagreen]