LoginRegisterCommercial SupportContact Us

Content Management > Managing Large Files

Managing Large Files

posted on 7:28 PM, November 14, 2008
Large files are a problem on the web, because they take so long to download.  For this reason, it is always recommended to compress media files (such as images and movies) before presenting them to the public on your website.  High degrees of compression can reduce quality, so you have to judge what tradeoff between download time and quality is acceptable, remembering that not everyone has an Internet connection that is as fast as yours.

Sometimes you need to post files that are very large, but are not traditional media files that can undergo extra compression at the expense of quality.  Examples include large ZIP files or other archives, PowerPoint presentations, large PDF files, data sets, and so on.  These are treated as "documents" by ExSite, which means that if you display one of these content items on your site, ExSite will automatically convert it to a download link to allow the user to grab the original file.

How Big is Too Big?

One megabyte takes about 10 seconds to download on a reasonably quick internet connection, and a few minutes on a dial-up connection.  Waits can be longer if you are not getting good bandwidth due to traffic or poor line conditions.

Media such as images and movies will often display when only partly loaded, so the problem is partly mitigated.  If the movie play rate is slower than the download speed, movies may start playing relatively quickly.  (Although this can depend on the viewer's browser or media plug-in settings.)  However, if the download speed of a movie is slower than the play rate, the user will effectively have to wait until the movie is fully downloaded before it begins to play.  This is unsatisfactory, because to the user it appears as if they have clicked to play, and then nothing happens for a long, long time.  Unless they are savvy enough to understand that they are downloading a large movie file, the movie will simply appear to be broken.  To deal with this, you can either include some text to explain the long wait, or you can shrink the movie file.

There are limits to the size of files you can archive in the CMS.  There are two reasons for this:
  1. Site editors may forget that they should take special effort to ensure files are reasonably trim and web-friendly.  If you upload an excessively large file, ExSite may assume that you have neglected to do this, and will not accept the file.
  2. ExSite saves all revisions of content into the database, and the database has limits on the maximum amount of data that can be transferred in a single operation.  If you try to stuff a file that is too large into the revision archives, the database will refuse to accept it.
For these reasons, the default limit for upload files into the database is 1 MB.  This is reasonable for day-to-day handling of regular web content such as images, small documents, etc.  If you hit this limit, take it as a hint that your file is not web-friendly, and see if you can shrink it first.  If you cannot, there are a few work-arounds:
  1. Raise the limit.  The 1 MB limit is fundamentally restricted by the underlying database's query size limit.  If your database allows for larger queries, you can raise this limit to match.  If not, you must first reconfigure your database to allow for larger queries.  To set the filesize limit in ExSite, use a configuration setting like:  bigfile_maxsize = 8388608
  2. Bypass the database.  Some advanced CMS tools detect that you are uploading a large file, but rather than error out, they bypass the database and write the file direct to disk.  The database only gets the file location, rather than the complete file data.  This gets the job done, but it should be understood as a bit of a "hack" because you do lose some useful revision handling features:
  • if the file is overwritten or deleted (such as if you unpublish), you will not be able to recover it from the revision management archives.
  • similarly, you may have problems with rollbacks or restores, because the revision management system only tracks the file location, not the file data itself.
  • files written direct to disk only have limited access-control features, since any user who can figure out the URL can access the file directly.
If this becomes a problem the only reliable solution is to upload the file again.

How to Upload Large Files

Casual users will often find their attempts to upload large files will be blocked, or in some cases (eg. with images) the files will automatically be scaled down in size.  These limits are in place because it has been observed that most casual users do not give much thought to file size or bandwidth, and may not even know what to do if they learned that their files are too large.

Advanced users, however, have ways to bypass these restrictions and get their large files uploaded into the CMS exactly as they provide it.  It is assumed that users with enough knowledge to use these advanced tools will also take care to ensure the file is web-friendly, so the system does not police their actions.

Method 1:  Website Manager "update" function.  This is the standard way of performing content updates using the Website manager.  If oversize files are detected, it will automatically bypass the database and publish the file direct to disk.  The revision handling system will only get a pointer to this file.

Method 2:  The Upload plug-in always bypasses the database and publishes files direct to disk.  (Even if the file is not oversized!)  The way it works is you select your section, library, and content object, and then upload a file to that location.  If no content object is selected, a new one will be created.  Otherwise a new revision will be added to the one you selected.