Your analogy is reasonable.
The queries typically take 8-12 seconds each. If there's a problem, they have a 30-sec timeout.
If I submit 50 of them serially, that can take quite a while. But since they spend most of their time waiting, it should process the whole batch asynchronously in 20 seconds or so -- a few seconds longer than the longest one.
But I'd like to display updates on the page that shows results as they're completing. It looks more interesting than showing a whirlygig for 20-30 seconds.
Right now I'm sending one request at a time. I'll give it a try to see if a blast of them at once will cause any problems.
But it would be easy to put the queries into a stringlist and send that up to the service, then have it go through that list and blast them out asynchronously, collect the results, then return them when it's all done.
I'm not sure there are any tradeoffs unless the volume of simultaneous requests to the service starts growing steadily and risks saturating the server. But I imagine I can always just add more CPU cores to the account.