My company replaced an aging SQL2008R2 server with a new SQL2014 server. The server, both in its old and new forms, acted as both distributor and publisher in the replication of about 40 merge publications, 100-150 articles per publication. The publications are scheduled to synchronize nightly to a subscriber SQL2008R2 server (on our LAN) and their start times are staggered to reduce server load. All subscriptions are pull subscriptions.
We recently did an update that affected every record of one of the highest row count articles in each publication. In some publications this approaches hundreds of millions of rows. Typically this article synchronizes changes at a speed of about 4000 rows per second. When attempting to synchronize these large changes from our new server the speed of dropped as low as 25 rows per second, even when we ensured that only one synchronization was running at a time and there was low activity on the publisher and no other processing on the subscriber.
Because we still have the old 2008R2 server on our network we have been able to test replicating large changes from that server as well, but we do not see the same issue. We have been able to verify that the 2014 server's publication and article settings exactly match those of the 2008R2 server it replaced. We have also checked to ensure that the Agent Profile settings for each replication agent are the same between old and new servers.
While we recognize that such a high update volume is not an ideal scenario for merge replication, we do not see the same behavior when replicating from 2008R2 to 2008R2 machines, only when replicating from 2014 to 2008R2. Therefore we are wondering if this issue should be reported as a bug? If that is the case, how would one go about doing that?