(721f) Our starter set grants 200 cards in 5 groups of 40 cards. We've seen some database throughput issues just today(in the last hour or so). Is this a known issue, or is something else going on?
I can add in code to retry these grants; I could move them to a playstream-driven grant (is this more reliable than an API call?)
Granting large numbers of items to players - especially stackables, and especially to players that already have large inventories (though it sounds like the latter isn't the case here) - does have known issues, yes. We've had a few discussions on that in the forums and in Slack. Using a PlayStream grant isn't any more or less efficient, as it's the same grant code behind the scenes.
For the grant operation, are you calling the grant with all the items, with a bundle, or with a container? Are you ensuring the calls are serialized, so that you only ever have one request in flight at a time? What delay (if any) are you placing between instances of these calls?
There are some optimizations we've made to the inventory service for the grant call itself as well as for bundles, and there are more optimizations we're working on in upcoming sprints.
as a list of items. Can switch to bundles easily. We wait for each one to complete before firing the next *for*any*one*player* (two+ players can be in flight from the same server at the same time); I've seen the first fail more often than later ones. No delay yet. Can add a little delay without too much hassle.
No, there's no difference in performance between a list and a bundle - it's just containers that haven't been optimized at all yet.
I'm actually surprised that you saw the first fail, but if you have a lot of duplicated items in the set, that could be the case. If so, you may want to try splitting this into more like 10 groups of 20 cards, to be safest. Waiting a few seconds between each call (for a specific player) would certainly help.
2 People are following this question.
