Improving Large File Uploads into an ECM by 95%

With the digital transformation of traditional ECM processes, file sizes continue to increase due to more video content and other rich media.  Regardless of the ECM solution (Alfresco, Documentum….), one of the biggest issues around digital transformation surrounds uploading large files, particularly in a synchronous mode where users want to upload the file and immediately process the file.  This post will highlight some innovative approaches TSG is currently recommending to clients surrounding the performance of ECM file uploads.

Large Files and ECM – What are the issues?

To understand why large files take so long to upload into ECM systems requires an understanding of the underpinnings of Enterprise Content Management.  ECM systems typically manage their own file stores and expose an API to allow content to be placed into that content store.  For a typical file upload process from a browser client:

1. User identifies a file that requires upload. (Select File or Drag and Drop to Web Browser)
2. The file is uploaded from the client to the application server via HTTP protocol over TCP/IP.
3. The file is processed through the ECM system (API) to store into the managed content store.
4. The user, after waiting for 2 and 3 to finish, receives back notification that the file (or files) have been uploaded.

The delays in uploading large files are typically found both in the application server as well as the ECM API.  Many times, clients will implement an asynchronous approach where files are dropped off and added to the ECM system at a later time rather than have users wait for the upload to complete.  While this approach is often acceptable for back-end migration efforts, typical user scenarios and processes often have the user wanting to upload and then tag/annotate and process the file rather than work on something different while awaiting for the long upload to complete.

Object Store and S3

TSG has had considerable success in reducing the time of large file upload both for users as well as large migrations by moving content directly into the object store and linking (rather than uploading) the files to the ECM repository.  Typically Object Stores (or Amazon S3) are built for ingestion of large files.  While a user might not notice any difference with the linking option, the process is very different.

1. User identifies a file that requires upload. (Select File or Drag and Drop to Web Browser)
2. The file is uploaded from the client directly to the object store/content store via HTTP protocol over TCP/IP.
3. The file is linked with the ECM system (API).
4. The user receives back notification that the file (or files) have been uploaded.

TSG has seen processing times improve 10 to 30 times by linking rather than the tranditional ECM method of storing documents.  The approach above also has additional benefits in regards to reducing the processing requirements of both the application server and ECM system.

ECM Storage versus ECM Linking Results

TSG has one large client leveraging the Hitachi Content Platform (HCP) as well as multiple Amazon S3 customers that are having success with the ECM linking rather than ECM storage approach within our Alfresco practice.  For results:

• Hitachi Object Store – for a large insurance client (1 billion objects), linking was used within the migration effort to dramatically improve the initial migration (that included renditioning) to up to 200/documents per second. Linking is being used throughout the daily ingestion activities.
• Amazon S3 – TSG has conducted multiple evaluation efforts for Amazon customers to including linking in both the initial migration as well as ongoing ingestion with large increases in performance.

Improving Network Speed – Aspera

Internally, TSG has been working with Aspera to improve upload performance for network speed.  Aspera has a rather unique approach.  Leveraging their own FASP transport technology, Aspera moves content quickly and securely over existing WAN infrastructure that is often hundreds of times faster than FTP and HTTP.  Much like bittorrent, Aspera breaks a file into small parts and quickly and redundantly sends them across network to the server leveraging the underlying components of the network.  For our internal tests, we really found that network speed was the limiting factor.  Some other observations:

• One downside for leveraging Aspera was the need for a browser side plug-in to leverage the FASP transport technology.
• While installing the plug-in could be an issue, the upside is that once the transfer is initiated, the browser window could close and the upload would continue.
• Security, Retries and other nice to have’s are included with the plug-in.

Summary

Whether for initial migration or ongoing migration of more and more rich digital content, ECM users are looking for ways to improve file upload performance.  Object Linking and improving network performance with Aspera are two easy ways to improve synchronous large file uploads.

Let us know your thoughts below.