Efficiency of sending multiple Fax requests batched together

LesMurphy

In another post, skamens wrote:

By the way - we do have options that would allow you to include multiple deliveries in a single job, with customization on a per-recipient basis.  That is more efficient for the system and probably for your code as well.  Is your application such that this would be a possibility?

I am seeing times on the test system of about 1-2 second to submit a 2 page Fax.  We were thinking that to keep our error handling simple we'd submit just one Fax at a time.  Each of our Faxes goes to a different phone number, and we only send each Fax to the single destination.

Is the response time on the prod system roughly the same?  We might end up sending 100 or so requests per minute in our busiest times.

What would be the recommendation in batching up the requests?  Would we see better API throughput and cause less load on your system if we send over batches of 10 or 20 faxes?  

Also, how likely is it that we would get an error back while submitting a Fax?  It seems like it should be only a rare exception such as a service outage at Easylink or some corner case in our code that would cause  a failure.

If we batch them up, we would have some additional processing to do in order to retry a failed request.  If in practice we will almost never get an error, then this is not a significant issue.

Also, if we submit a number of requests in a batch, I assume we get back a unique jobid for each Fax?  Or do we have to track that in our code to match up the CDR records to the individual Faxes?

 

skamens

A time of 1-2 seconds for the processing of your API request is pretty typical.  The system should probably be able to handle 100 such messages in a minute if it had to, but that's something you should review with your Sales Engineer before you transition to production.  Our capacity planning team would need to get involved to make sure all of the system components are in place to handle the volume.

As for batching - there's not much to be gained by batching multiple independent jobs into a single JobSubmit request - the system still has to do essentially the same processing for each one.  If you were to batch them up to something like 10 at a time, that might help a bit in terms of the initial request/response setup and SSL negotiation and such, but the difference is probably negligible.

The real thing to look at is whether you would be able to group multiple recipients into a single job.  So the first question to ask is whether your content is such that it could be batched up that way.  The system has a few different ways of allowing personalization of an individual message (for example, using MS Word Mail Merge), so each recipient could still get different content while still being part of the same job.

This approach is much more efficient all around than multiple single jobs.

If you did it this way, then you would get one job ID for the group of recipients, but you could track each recipient using an item level reference ID.  And as we discussed on the other comment thread, you would have to iterate the DeliveryDetail to get status for each of the items.

If you needed to resend a specific recipient, we have resend functions that will work at the item level.

So the big question is what does your content look like, and could it be reduced to a template with personalization of some sort.