VM Sizing

As with all aspects of cloud, performance will vary depending on the resources you allocate.  GCP bandwidth is a shared resource.  Larger VM sizes will more often receive a larger share of GCP bandwidth.  A minimum size of n1-standard-4 is recommended.

Reporting

Clients display the progress of uploading data to the CloudDat instance.  It may take several seconds more for the data to then finish being written into GS.  There may be times when GS takes up to a minute to confirm receipt of the data.

Network

Data cannot move faster than your underlying network and storage hardware.

The GCP VM hosting CloudDat must be in the same region as the GS bucket.  Accessing a bucket in a different region than the gateway instance will severely limit performance.

Because each transaction must establish communication between the VM and GS, it may take several seconds for each action to start.  If you are storing large numbers of files in GS, consider packaging related files as a ZIP or TAR archive, rather than storing each file as a separate object.  Remember that GS "objects" are not quite the same thing as "files", even though CloudDat will do its best to make them look like files.

Folders

Folders do not exist in GS buckets.

For the purpose of listing remote files, pseudo-folders are displayed by grouping together objects sharing common name prefixes ending in "/".

While pseudo-folders allow you to browse the contents of a bucket as though it were organized into folders, some folder related functions will not work with GS.

• The "Rename" function cannot be applied to GS pseudo-folders.
• The "New Folder" function is silently ignored.
• Empty objects with keys ending in a "/" are ignored.

To use ExpeDat Desktop to upload objects into a pseudo-path that does not yet exist, type the path in the "Remote Prefix" field prior to clicking "Send".

Listing a bucket containing many objects may take a long time, even if they are grouped into pseudo-folders.