We have a defined and well running transactional replication process. One publisher, one distributor (on separate servers) and several subscribers (pull). All servers have Enterprise Edition.
Latency checked using a canary table. I use a canary table on all subscribers instead of tracer tokens. Don't see any additional latency. There is a great article by Kendra Little showing that canary tables are very good for this measure, since tracer tokens are too patient.
The replication is not for the whole database, only several tables, but the tables are relatively big and there are a lot of inserts.
I added one more subscriber using Standard Edition. It runs well and has no issues except it shows more Latency issues, not huge but it is alerting much more than all other subscribers.
How can I handle this issue? Is it possible to improve? What should I check? If the server is outperformed on inserts, what should I do to improve it?
Information added in response to comments
The Standard Edition server itself is the same as the other subscribers. All servers are created by DevOps using the same configurations. We have 12 CPU cores on all the subscribers. The Standard Edition subscriber usually performs the same as all other subscribers (Enterprise). Only some times it starts to show increasing delay (30min-1hr) and it takes more than hour to recover.
PLE is 55146 (on Enterprise subscriber it is 178775). The main wait stats on the Standard subscriber are:
The latency is between the distributor and the new subscriber. It usually serves ok and shows no latency as for all other subscribers. But once or twice a day it show latency that at its peak gets to 30min-1hr. I find that it happens when there are thousands of updates coming.
The tables are not partitioned. Everything in replicated tables suits Enterprise & Standard.