Compression and Encryption Resource Usage
StoragePoint offers the options of compressing and/or encrypting external BLOB files on a given endpoint. The compression option can provide better storage utilization by shrinking files and the encryption option can provide for better security of blob data both during transmission and at rest. However, since both options are implemented in software and not hardware, there is a resource cost associated with using them.
Both software compression and encryption utilize CPU resources. The amount of CPU used for compression varies depending on the size of the files and whether they are already compressed or not (i.e. PDF, DOCX, XLSX, etc.). Larger files and files that are already mostly compressed can utilize substantial CPU resources during compression processing. The amount of CPU used for encryption can increase depending on the size of the file (larger file sizes use more CPU resources).
Here are some general guidelines to consider when deciding whether to use compression and/or encryption on an endpoint:
·If the server or VM environment of the WFE is underpowered - i.e. too few processors/cores allocated, older/slower CPUs, etc. - then consider not using the compression and encryption options. We recommend no fewer than 2 actual cores be dedicated to each WFE if these options are use. Four or more actual cores is preferable.
·If the environment is a VM, ensure that actual CPUs and cores are being dedicated to the VM. A virtual CPU allocated to a VM does not usually map one-to-one to a physical core or CPU. So if a VM host contains 1 CPU with 4 cores and there are 8 VMs running on it, there is not a one-to-one mapping of cores to vCPUs.
·Compression is not effective on files that are already compressed. Note that most PDF files, Office 2007/2010 files and media files (JPEG, MPEG, etc.) may already be internally compressed. If the bulk of files being externalized are these types of files, use of compression should be avoided as it will just waste CPU resources and yield little to no compression.
·Large files (greater than 20 to 30 MB) may take large amounts of CPU to compress. If compression must be enabled, consider tuning the compression setting on the General Settings page. A maximum compression size can be specified that will stop compression for files above a certain size threshold. Also, the overall compression level can be modified to ramp down the amount of compression that will be achieved but also save CPU resources.
·Compression/encryption cannot be changed once the endpoint is saved. To change these settings, the content will need to migrated or recalled, the endpoint deleted, and then recreated with or without the change to the compression/encryption settings.
Editing an Existing Storage or Backup Endpoint
While certain aspects of an active storage endpoint can be modified, one should take care when performing this operation as content can become irretrievable.
|
|
NOTE: Compression and encryption settings on an active storage endpoint cannot be changed. These fields will be disabled. To change these settings, run the Recall or Migration job to move content back into the content database or to another endpoint (decompressing and decrypting it along the way), create a new endpoint with new settings, and then run the Externalize or Migrate job to move the content out of the content database. So plan accordingly. |
1.Open the endpoint by clicking its name on the Storage and Backup Endpoints page.
2.Make the necessary changes. See the chart in the specific adapter guide for clarification on fields.
3.If changes are made to the Adapter or Connection property in the Storage Settings section there will be a warning about the possibility of content becoming irretrievable.
4.Click Save to apply the changes.
Delete or Retire an Existing Storage or Backup Endpoint
While safeguards are in place to prevent externalized content from becoming irretrievable, deleting a storage endpoint is still an operation that should be carefully planned and completed.
1.Open the endpoint by clicking its name on the Storage and Backup Endpoints page.
2.Click Delete.
Storage endpoints that are associated with a Storage Profile cannot be deleted, and if attempted will return a message like this:
3.If there are other endpoints that can be used for that profile, the endpoint can be retired.
|
|
NOTE: Backup endpoints cannot be retired and a successor endpoint is not an option. Disable the Backup Sync settings on a profile to cease backing up BLOBs, or select a different backup endpoint for the profile. |
Select a Successor Endpoint from the dropdown, and click Retire. Selecting a successor endpoint wont be visible if there are not any profiles using the endpoint.
A bulk migration job will be performed automatically to move BLOBs from the retired endpoint to the selected successor endpoint, for each profile affected. The endpoint will be in a retiring state while this is going on.
4.If the endpoint can be deleted, it will be, and the Storage and Backup Endpoints page will load.
Deleting an endpoint makes all content on that endpoint read only.
Troubleshooting
Problem: Problems with Excel Services or other SSP service with StoragePoint installed
1.When using the FileSystem adapter, make sure that the account under which the SSP Application Pool process is running has been granted access to the BlobStore.
2.Make sure that the account under which the SSP Application Pool process is running has been granted access to the StoragePoint database. They will need both DataReader and DataWriter permissions.