共用方式為

RMS Performance: File API throughput

  • 發行項

Hello,

We've got some important performance information to share with you regarding time related to file size graph for File API for Office, PFile and PDF . Here's Akshay with the information.

Thanks,  
Dan

...

Hi folks,

I'm Akshay Dhavle, an SDET on the RMS team.  Since the initial preview release of the AD RMS File API, we've gotten lots of questions regarding the File API’s performance and throughput.  In this blog post, we’ll share our official performance measurements for the File API SDK which is part of AD RMS SDK 2.1 Release Candidate (RC).

We’ll deal with four file formats here:

  • PDF
  • Office 2003 formats (e.g., .doc)
  • Office 2007 (and above) formats (e.g., docx)
  • Microsoft’s Protected File format (e.g., pfile)

Any file types you need to protect should fall under one of these categories.

How the data was gathered:

  • We used hardware with 8 GB memory, an Intel Q6600 CPU, and 2x500GB drives in a RAID 0
  • To make the measurements repeatable we used just one thread, so only 1 CPU core was in use (and was maxed out)
  • The first calls to IpcfEncryptFile and IpcfDecryptFile were excluded.  The first calls generate and acquire certificates from the RMS server, and take longer than each subsequent call. 
  • For IpcfDecryptFile, cached licenses were used to simulate common client DLP application scenarios.  Depending on the goals of your application, IpcfDecryptFile may generate additional network traffic beyond what was measured here

 

 

 

 

We hope this data is useful for you! 

As always, if you have any questions or feedback, contact us on our connect site.