Coppermine Photo Gallery v1.5.x: Documentation and Manual

Performance tips

Here are some tips to get the best performance from your Coppermine gallery. It covers changes you can make to both Coppermine's configuration and your server configuration (if you have access to that of course).

Configuration settings

Many of the configuration options have performance implications. Some features can cause load issues when used on large galleries or galleries that are structured in an unusual way.
The general advice is to disable any feature you don't actually make use of and to keep any numeric options sane.

General

Things that increase server load generally

Number of <something>

Keep the number of anything set to reasonable values, the defaults are usually fine for most galleries.

Many users who had issues with enabling uploads in the first place thought that it was a good idea to set the maximum file size to a ridiculously large number, e.g. several terrabytes. That is of course total nonsense and usually results in quite the opposite of what they intended.

If you don't use plugins, you can disable the plugin system entirely. Don't add all known plugins to your gallery - just add those that you need. Don't add plugins blindly - some of them try to accomplish similar things and therefore often interact in an undesired way. You can disable individual plugins on the plugin manager page to troubleshoot speed and server load issues. A disabled plugin doesn't do anything except be listed on the plugin manager page.

Non-English language

Displaying your gallery in a language other than English (US) carries a small performance penalty.

Keep this setting simple so your index page loads quickly. Avoid using the random block on very large galleries. The "lastalb" (last-updated albums) block can be slow on very large galleries, particularly if you have the album thumbnail set to "random" or "last uploaded" for most albums.

Disabling this will help keep the database small. If this feature get's enabled, your database will increase dramatically if your gallery is busy. Instead of enabling the hit stats you should consider implementing a full stats tool like Google Analytics that can easily be integrated into your coppermine gallery.

This causes a small delay while the news is fetched. Only applies for the admin, so your site's visitors won't notice a difference. It's recommended to keep it enabled, but if you're a speed freak, turn it off.

Choosing "Last Uploaded" or "Random" for an album thumbnail adds extra queries for each such album shown on a page. Choose a specific image to avoid these queries.

Spiking

Things that can cause load spikes on specific pages. If you are on a shared server you should avoid creating load spikes.

Allow ZIP-download of favorites

Creating zip files on the server is resource intensive.

Enable clickable keywords in search

Loading the list of clickable keywords can take some time if you have a lot of them.

Process concurrency for batch-add interface

Keep this small; a value of 1 is best to keep load down when batch adding.

Display preview thumbnails on batch-add interface

Building the preview thumbs can be resource intensive.

Comments per page

If you have a lot of comments make sure this is set to something reasonable. Having 1000 comments displayed on one page will cause it to load slowly.

Method for resizing images

If you use GD you may hit PHP resource limits. If you use ImageMagick you can evade some resource restrictions since it runs outside PHP.

Read EXIF data in JPEG files

If this is enabled the image will take longer to load the first time it is accessed as the EXIF data is read.

Watermarking

Watermarking your images on the server will use more resources. Watermark before uploading if possible.

SMTP

Offloading your email sending to another server or provider may help. Effectiveness of this depends on how many email related features you use.

Server settings

There are some settings that are not directly related to coppermine, but to the webserver. If you're webhosted, you usually can't manipulate them. Changing your server setup goes unsupported on the coppermine support board. However, it's recommended to look into those settings as well - maybe your webhost can change things for you.

PHP settings

If you have control over your server you can improve Coppermine's performance by adjusting your PHP configuration.

Use the latest version

Use the latest stable version for best performance - PHP 5.2 is much faster than previous versions.

Use a PHP accelerator

These can cut page load times by 40% or so. Note: Coppermine won't use any data caching ability but will benefit from bytecode caching. See list at Wikipedia.

MySQL settings

If you have control over your server you can improve Coppermine's performance by adjusting your MySQL configuration.

Use the latest version

Use the latest stable version for best performance.

Enable the query cache

This helps both reduce server load and page load time.

Tune the configuration

OPTIMIZE your database tables

Running an OPTIMIZE on your database tables using phpMyAdmin can help improve performance, especially after major updates to your gallery's content. You don't have to be the server admin to perform this query - it will suffice to have the permission to execute that query (which is the case for most users on shared hosting as well).

Third party tools

There is a number of third party tools that can help you to improve the performance of your gallery. Please note that the coppermine group is not affiliated with any of those tools nor do we support those tools.

YSlow

By adding an .htaccess file containing the following code into your Coppermine gallery directory you can apply some of these suggestions. If you do not use Apache as your webserver you will need to find the corresponding configuration settings for your webserver of choice. If your site no longer works after making these changes you can simply rename or delete the .htaccess file.

4. Gzip components

Coppermine doesn't work very well with output compression, as it was not built with that in mind: it jumps in and out of output buffering quite frequently, that's why it probably doesn't work very well with output compression.