Limits on number of merge subscribers?

I'm testing merge replication between a SQL server 2000
publisher and multiple MSDE subscribers. The publication
consists of somewhere around 200 articles (tables, views,
store procs). All subscriptions are pull subscriptions.
My test environment has roughly 10 subscribers.
So far the solution seems to work nicely.
Does anyone know what kind of performance issues I may run
into if the number of subscribers increased to 50 or 100?
It there a theoretical limit or is it simply a question of
machine capability and band width?
Pat,
I haven't ever used more than a dozen simultaneous subscribers, but this
article details scaling up to 2000 subscribers and the correlation with
download speed, effect of RAM, processors etc:
http://www.microsoft.com/technet/pro...mergperf.mspx.
BTW, as far as I know there is no documented limit to the number of
subscribers.
HTH,
Paul Ibison

Limiting number of merge processes

If with a merge publication we limit the number of simultaneous merge
processes say to 5 for 100 subscribers, do the 'waiting' merge agents
complete their tasks in an orderly queued fashion or is it just pot luck in
what order they complete? Is it possible that certain agents might be
'unlucky' and only infrequently complete the task.?
Its a fifo type process. The first 10 merge agents connect and
download/upload changes. The next ones wait until the first set complete.
The merge agents in the queue wait a predefined time - set by the
StartQueueTimeout parameter. If one or more of the first 10 agents complete
and the StartQueueTimeout parameter has not exceeded for the waiting agents,
these agents will then start processing. If the StartQueueTimeout parameter
has exceeded the agents themselves will timeout and try again.
"Tony Toker" <xyzzy@.identic.co.uk> wrote in message
news:cqblv5$eeo$1$8300dec7@.news.demon.co.uk...
> If with a merge publication we limit the number of simultaneous merge
> processes say to 5 for 100 subscribers, do the 'waiting' merge agents
> complete their tasks in an orderly queued fashion or is it just pot luck
in
> what order they complete? Is it possible that certain agents might be
> 'unlucky' and only infrequently complete the task.?
>