Gallery 2 Performance Tips
Tuning the performance of your Gallery 2 can and should be done in all involved components that you can influence. That is, configuring Gallery 2, PHP, the webserver, the database, the operating system and choosing the right hardware. Of course a super fast webserver in Siberia won't help if your users are located in Californa or if the internet connection of the webserver has a too small bandwidth (delay, bandwidth).
Summary
You can get the biggest performance increase by enabling a PHP accelerator and enabling caching (via Site Admin » Performance). After that, switching to PHP5 is probably the biggest performance gain. In many cases, these changes alone can give you a 2-4x speedup.
PHP
- Use a PHP Accelerator/Cache, recommended is eaccelerator among others. The Zend Optimizer is not an opCode cache and doesn't help G2 performance very much, while a true PHP cache can dramatically improve G2 performance. See: List of PHP accelerators.
- Set output_buffering to a reasonable size. Either Slightly larger than the average photo size of your G2 or if that is too high, maybe to 1048576 (1 MB) or less.
Warning: Progress bars won't work anymore since the output is buffered. So Apache might even terminate PHP and your Gallery 2 operation (e.g. maintenance, upgrading, tasks that take a long time) might leave the database in a corrupted state.
Remember: each and every PHP process will allocate a buffer of this size if it needs it or not. So don't even think about setting this to 50 MB or so (remember, each thumbnail spawns a separate PHP DownloadItem process!).
Printing data from PHP to your browser can be 2-3+ times faster that way (compared to no output_buffering) because PHP / the webserver can merge multiple print statements into a single one and there's less overhead involved that way on various levels.
Hint: A trick to benefit from output_buffering speedup without losing progress-bars / reliability is to use GalleryEmbed! If your Gallery 2 main.php (g2Uri) is in another folder than the GalleryEmbed access point (embedUri), then you can use different php configurations (php.ini / .htaccess / httpd.conf) for DownloadItem requests and pretty all other G2 requests. Use output_buffering for the gallery2 folder and no output_buffering for the folder where your new Gallery 2 access file (embedUri) is in.
- Disable session.use_trans_sid since it's not required in G2. G2 versions since G2.1 do that automatically for you if ini_set() isn't disabled.
Database
- MySQL, PostgreSQL, Oracle, and DB2 have all various configuration settings like buffer size etc. And one can improve performance considerably if the DB server is properly configured.
- Fast harddisk drive
- Using a solid-state / RAM-Disk or a RAID-0 will boost the DB access too of course
- G2 is mainly developed on/for MySQL. Expect the best performance with MySQL. PostgreSQL is also tested regularly, Oracle and DB2 have had much less testing. DB2 is also using some quite inefficient/slow workarounds in some queries.
- If using MySQL >= 5.0, use the mysqli driver instead of the plain default mysql one.
- If you're using PostgreSQL, disable SSL in your postgresql.conf if possible.
Filesystem / Memory
- ulimit -a settings
- Fast harddisk drive
- Using a solid-state / RAM-Disk or a RAID-0 will boost the filesystem access and loading of the G2 framework too
- No symlinks
Webserver
- Proper concurrent requests handling configuration (StartServers, ...)
- Disable mod_deflate and other compressors for the gallery folder. The reason is that mod_deflate tries to compress the output of G2 before it's sent to the user. And G2's main.php not only outputs HTML, but a lot of binary data (images) as well. Trying to compress this does not only cost a lot of CPU, there's also almost no gain in bandwidth. G2 sets proper content-type headers, but mod_deflate ignores them, even when you try to configure it properly.
- Disable FollowSymLinks (Apache)
- Disable .htaccess (AllowOverride, Apache)
- Use a HTTP/1.1 webserver (Keep-Alive) and generally, make sure the data is transmitted as efficiently as possible (no use of mod_bandwidth, mod_throttle, ...), large bandwidth, location of the server as close as possible to the clients, ...
Gallery 2
Gallery 2 performance has a lot room for improvement and the development team will work mainly on performance improvements probably right after G2.1 has been released. G2.1 is already considerably faster than G2.0/2.0.x.
- Go to the Site Admin -> Performance tab and enable max acceleration. This will cache page views and result in a significant speedup on sites where the content doesn't change all that often. For some reason, this feature doesn't always speed up G2. Disable it if necessary.
- Use persistent database connections (config.php) if your webhosts allows it. You should definitely discuss this with your DBA / webhost before enabling it.
- After massive changes, optimize the database (site admin -> maintenance)
- After massive additions / changes, also add / remove a permission for a single item a few times to trigger an ACL / permission table compaction.
- Don't use a lot of useralbums. This is a shortcoming of the current permission architecture of G2, it scales very badly with the number of ACL IDs (the more different the permissions for different items/albums are, the more ACL IDs you have). This will be corrected soon.
- Locking (Site admin -> General): Use the locking type that is faster for your server. Usually, that's file based locking (flock) and not database based locking.
- Don't add too many blocks to your pages. Each block loads its own data and the more stuff you add to your page, the higher is the complexity of each request.
- Keep as many images public (viewable to the everybody group) as possible since there are some optimizations in place for public items.
- Certain themes load much more data than others, other themes show a lot of images on a single page. This will always come at the price of worse performance
Modules
Some modules don't scale as well as others. Others are already slow for small photo collections. Here are some warnings:
- useralbum - Don't use it for a site that is highly frequented and has a lot of registered users with useralbums. This is due to our current design of ACLs / permission mangement.
- exif - If you're dealing with larger images, disable this. See: bug 1376094
- imageblock - There's certainly a performance hit when using the imageblock module, probably it doesn't scale as well as the core Gallery.
- randomhighlight - Don't use small delays. Gallery has to generate the thumbnails on-the-fly when the randomhighlight timeout is reached.
- captcha - Good for your performance! Not only prevents comment spam, but should block comment spam attacks early in the process thus blocking additional requests. This should more than compensate for the dynamically generated captcha challenge images.
- rewrite - URL rewriting is fast. But not if you use it with PathInfo and then enable the DownloadItem rule. Also, watermarking hotlinked images is also expensive since those images are not cached yet.
- zipcart - Excessive use of zip downloads are also pretty CPU intensive.
- slideshow - can be very, very CPU intensive if search bots are hitting it. Disable it or use robots.txt to block search engines from hitting it.
Tips by other Authors
