1 of 1 people found this helpful
Of your listed options, #4 for sure. In the mean time, adding an additional backgrounder process or two does help. We have a high-extract environment on an 8-core server and going from 2 to 3 and then 4 backgrounders made a world of difference for us.
Use the parallel setting. Use the Serial setting if you must have one object update before another.
Priority won't help unless you have very important ones that must get out first then you would set them to a small number like 1 or 2 etc. A Priority of 100 has the least importance.
< edit > Given Matt's excellent response I've modified my response as I was incorrect Sorry about that.
A little-known fact about subscriptions: They are always processed serially for a given Schedule, despite what the Schedule settings say. Only one (1) backgrounder process will be used. This means that in today's world, if you want them to run in parallel with each other at the same time, you need to create additional schedules that run at the same time (e.g., "6AM - 1" and "6AM - 2"). We currently have 8 schedules for our 6AM subscriptions. This is not only messy from the user experience perspective, but also creates additional work for the Admin since you have to balance the number of subscriptions on all the schedules every couple of weeks or so. But it's the cost for timely subscriptions when people subscribe so frequently.
Once you have parallel schedules set up, also doing #4 will definitely help. Note that for extract refreshes running in parallel (which does work as expected), they are highly CPU intensive--so adding more backgrounders to your host will also increase CPU utilization for extract refreshes. If your backgrounders are running on nodes that are also running other types of processes, you could begin impacting performance for users interacting with Server. Our configuration uses two hosts that are completely dedicated to running Background Tasks, which prevents our heavy extract refresh load from impacting users.
It's also worth mentioning that Subscriptions are not processed very efficiently right now. Each is processed individually, forcing a full data refresh each time, even if ten users have subscribed to the same view on the same schedule. You can work around it somewhat right now if you create a new User, set the email address to an alias, then subscribe as that user to a view that everyone on the alias needs at the same time. But that's a decent amount of work to manage and will likely only help a bit. Consider upvoting this idea to improve subscription efficiency!:
Thank you Matt, you taught me some good info
Glad to hear it! It might be apparent that I've been fighting this fight for quite some time now.
so would an Active Directory Group be a valid group? Sounds like that would work, but I'm not sure if that's what you mean?
So, I have a report that 15 people need so I just add them to the one distribution group.
What if I am passing in different parameters for the same report?
Marty Galvan wrote:
1. so would an Active Directory Group be a valid group? Sounds like that would work, but I'm not sure if that's what you mean?
2. So, I have a report that 15 people need so I just add them to the one distribution group.
3. What if I am passing in different parameters for the same report?
2. Yes, add them to one email distribution group.
3. And...? Not sure what you want to know If report X is used 15 times and each time requires different parameters then it is essentially 15 different reports so a single [email] distribution won't work.
1 of 1 people found this helpful
Hey Marty. The "send this subscription to a distribution list" workaround in the Server product requires a distribution list, e.g. "email@example.com". For us, distribution lists like that didn't live in Active Directory as Groups until we got off our older hosted Exchange provider. So it probably depends on how your IT dept. is running things. But assuming you have an email address like the above, with multiple users behind it, you can do it so long as you can assign that email address to a User in Server.
When you decide to use this kind of "broadcast Subscription" (for lack of a better term), you are basically affirming that you know that the information in it, as rendered by your custom User, is relevant and appropriate for all parties receiving it. So if you are using User Filters to show sales reps how they specifically are getting on towards their quota, this workaround isn't such a great idea. Likewise, if the different recipients of the email are all using their own Customized Views for the stuff that they care about, or if, like you said, they're passing in parameters (manually or via URL params), then the broadcast Subscription becomes less helpful.