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.?
>

Limitation in number of fields a Table published by push merge Replication may have

SQL 2000 SP3: There is a table with more than 254 Fields in it. (please
don't ask why :-) )
we observed, that replication on fields which are beyond the magic limit of
254 simply do not replicate.
( Enterprise manager says Replication takes place, but data do not show up
at destination.
Is this a known documented limitation ? Is it a bug with perhaps an
existing patch?
This is a known limitation. I'd consider splitting up the table into 2
separate related tables related and replicate them both. This can be made
transparent to the users by presenting them with a view which has the
original table's name and an InsteadOf trigger.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I consider this to be a bug:
The Enterprisemanager accepts the publikation,
The replication Monitor says "1 Insert Done"
but the data is lost.
I would have no objections if the enterprise manager said:
"are you mad this is nothing you should publish I can't publish tables that
are so large / task rejected"
But If It accepts the task It should accomplish the task.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uieZiLGFFHA.1564@.TK2MSFTNGP09.phx.gbl...
> This is a known limitation. I'd consider splitting up the table into 2
> separate related tables related and replicate them both. This can be made
> transparent to the users by presenting them with a view which has the
> original table's name and an InsteadOf trigger.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>