This is a fun question.
Obviously there's no conclusive answer and it depends on your specific infrastructure, data, etc etc etc...
But with that said, I've found that if your aim is maximizing how quickly you get data into the system, aiming for transaction bundles of around 1000 resources each seems to be the sweet spot (this assumes that you're firing many bundles in parallel and what you actually care about is how quickly you are getting your overall number of resources into the database).
In terms of how high can you go, the limiting factors are:
- How long does the database itself allow a transaction to stay open (typically a very long time and generally not an issue)
- How long does the HTTP infrastructure allow a transaction to happen, including the client, the server, and any intermediates. This is almost always an issue when you try to handle very large transactions. A 50k transaction bundle is going to take a while to process, and many parts of your HTTP stack aren't going to like having an HTTP request sit open but with no traffic for 10 minutes.
- How much memory do you have on your client/server, since we need to be able to fit the entire transaction bundle into RAM both on the client (usually) and on the server (always).
From what I've seen on various HAPI/Smile implementations I'd say:
- 1k is optimal (as I said above)
- 5k is a very soft limit where you don't usually have to do much work in order to support it
- 25k is a soft limit where you're almost certainly going to have to make environment changes (network, memory) in order to get there
- I've never really seen anyone exceed 50k (although this doesn't mean people haven't)
Cheers,
James