From the Trenches: Measuring Docusign platform performance
See how to measure the performance of Docusign eSignature REST API methods in your integrations through the API Usage Center.
When monitoring an application built around SaaS, it’s always interesting to measure the Docusign platform performances linked to the API functions being used.
For this post, I will limit this analysis to three main API calls: CreateEnvelope, GetDocuments, and signing an envelope in the scope of eSignature solution. This will allow us to see quickly what to expect in terms of transaction latency, depending essentially on the data size and the number of fields defined in the envelope.
An API transaction duration is decomposed into three main steps:
Time spent for the API query sent from the client to reach the Docusign platform. Docusign has no control over it, but a measure is available (merged with [3]).
Time spent on the Docusign server to process the request. Docusign has the control and measure of it.
Time spent to return the API query result to the client. Docusign has no control over it, but a measure is available (merged with [1]).
To benchmark the performance of Docusign API servers, I’ve made all these measures in the production environment, as presented in the sections below, corresponding to a running of several days on all platform traffic in order to be representative enough.
Of course, these results must be interpreted as indicators only, since, in the individual case, transaction latency depends on many factors inherent to the platform and the transaction payload: the Docusign resources available, traffic on the platform, the account server site, envelope specifics, and also external factors: network bandwidth, hardware limit, and so on.
Envelope creation
For this benchmarking exercise, I monitored the eSignature REST API envelope creation function Envelopes:create.
The measured times are the combination of the time spent on the server [2] and the time spent on the network [1+3].
In the graph below, four curves have been extracted as functions of the request size being processed: three curves are tracing the average transaction duration for different numbers of fields defined in the envelopes (≤5 ; 5<x<20 ; ≥20), and the last curve is tracing the 95 percentile (95% of all envelopes completing in that time or less).
As an example, for an envelope creation request embedding 1MB of data (see the first vertical tick bar), this graph shows:
The processing time, [1+2+3], can vary on average between 3.1 and 4.9 seconds depending on the number of fields set in the documents (dark blue, light blue, and orange curves).
Only 5% of the total transactions are processed in more than 9.6 seconds, whatever the number of fields (green curve).
As you can see, these datasets are quite volatile because they depend on many factors. It allows us, though, to derive a good trend indicator.
On the demo platform, we expect to have durations in general 40% higher than in production for this function.
Get documents
For this exercise, I monitored the eSignature REST API get document function EnvelopeDocuments:get.
The measured times are the combination of the time spent on the server [2] and the time to give the result to the client [1+3]: the green and blue curves.
Knowing that a lot of data can circulate from the server to the client when retrieving these documents, it is interesting to isolate the time spent to process the query on the server only [2]: the orange curve.
The processing time here is not dependent on the number of fields defined in the documents.
As an example, for a GetDocument request that returns 1MB of data, this graph shows:
The average processing time, [1+2+3], is 1.4 seconds (green curve).
Only 5% of the total transactions are processed in more than 3.1 seconds (blue curve).
The average processing time spent only on the server [2] is 1.1 seconds (orange curve).
As might be expected, the time duration is really dependent on the time spent on the network; and this ratio increases with the size of the documents, whereas the processing time on the server is quite stable.
On the demo platform, we expect to have durations similar to production for this function, since there are few processes created.
Signing an envelope
This is the signature made inside the signing ceremony through the Docusign web page by the envelope signer. The query is sent from the time the FINISH button is clicked and is terminated when the user regains control.
In the graph below, four curves have been extracted as functions of the request size being processed: three curves are tracing the average transaction duration for different numbers of fields defined in the envelopes (≤5 ; 5<x<20 ; ≥20), and the last curve is tracing the 95 percentile.
As an example, for an envelope signature embedding 1MB of data, this graph shows:
The processing time [1+2+3] can vary on average between 3.6 and 4.6 seconds depending on the number of fields set in the documents (dark blue, light blue, and orange curves).
Only 5% of the total transactions are processed in more than 8.6 seconds, whatever the number of fields (green curve).
On the demo platform, we expect to have durations similar to production when doing a signature.
How to get these transaction times for your own account
It is possible to extract these times for any individual API transaction in the API Dashboard under the Docusign web UI. That excludes signature operations, though.
They are labeled as:
Duration: Total time required to execute the operation, including execution of any downstream methods [1+2+3]
API Elapsed Time: Time to execute the request on the server [2]
How to troubleshoot API transaction slowness
It is important to determine first where the slowness is located: on the Docusign server, [2], or on the network, [1] and [3]. Then a comparison can be made between the values retrieved in the API Dashboard and the graphs given above.
From the machine running the API transactions, the internet speed must be high enough for downloads and uploads in relation to the supported traffic. Some online tools exist to test the internet speed, such as Speedtest.net
A network analyzer, like Fiddler, can help to get a breakdown of the time spent on several steps of the transaction. Here’s an example of an analysis made on the GetDocuments transaction with Fiddler:
Slowness can also be troubleshooted using the Trace Route command. It may enable you to diagnose network latency on specific points of the route to the Docusign server.
If a major performance issue has impacted the Docusign platform (problem identified on [2]), it should be reported as such on the Trust Center.
Additional resources
Sylvain Lebreton is a developer support engineer based in the Docusign Paris office. He has worked in different support positions and companies (telecom business sector essentially) for over 20 years.
Related posts
Discover what's new with Docusign IAM or start with eSignature for free
