4.4.2 dramatically improves performance in multi-gallery scenarios

4.4.2 dramatically improves performance in multi-gallery scenarios

By | 2018-02-07T16:21:20+00:00 February 7th, 2018|Uncategorized|0 Comments

Today we are releasing Gallery Server 4.4.2. As with the 4.4.1 release, we continue to focus on performance. Upgrading from 4.X is as easy as copying the files from the upgrade package over your existing files.

Performance gains

One of our customers, Reto Ambühler in Switzerland, was experiencing large wait times for several common editing scenarios, such as adding an album and creating a role. There was also a significant startup time for the gallery. He generously shared his database with us. It contained 64 galleries, 1403 albums, and 53,000 media assets.

We were able to reproduce his performance issues. For example, browsing to a new album took 55 seconds, deleting an album took 38 seconds, and deleting 10 empty albums took a staggering 6 minutes and 22 seconds!

Most customers do not experience such poor performance, even with several times more media assets. His scenario was unique because he had a large number of galleries, which amplified the amount of data that was loaded after any edits that purged the cache. We want Gallery Server to handle this scenario, so we went to work with our performance tools to see what we could find.

We found several places where we could make simple changes that dramatically improved performance. For example, when adding a role on the manage roles page, Gallery Server displays an album tree containing the gallery node and one level of child albums. In Reto’s case, that meant displaying 64 galleries and the first level of child albums in each, resulting in a dialog that displayed hundreds of albums. By changing this to show only the root gallery nodes, we reduced the time it took to display the add new role dialog from 95 seconds to 7.5 seconds, a 92% improvement. This had the added benefit of being much more usable as well.

Another area that had a dramatic impact on performance was some validation code that ran each time the gallery cache was purged, which occurred during many common tasks such as adding and deleting albums. This validation code looks for missing rows in the database and automatically inserts them. For example, if one of the gallery settings for a particular gallery is missing, this routine restores it by making a copy of the matching setting associated with the template gallery.

But in practice, the validation routine rarely fixes anything because the primary scenario where a row might be missing is when an administrator manually goes into the database and starts deleting records. And that should rarely, if ever, occur. However, we didn’t want to remove the validation altogether, because we couldn’t be sure how often it actually was being useful and possibly saving users a headache and us a support call. So we altered when it ran to once per application lifecycle. And we run it on a background thread so it doesn’t impact page load times.

This change, combined with a few others, helped reduce the time it took to delete ten empty albums from 6 minutes 22 seconds down to 2.5 seconds, an incredible 99.4% improvement!

The table below compares times for the same tasks conducted in 4.4.1 and 4.4.2. Notice they are at least 80% faster. While most of you will not see the same level of performance gains, especially if you have a single gallery in your installation, you may still noticed a snappier gallery.

Large, multi-gallery installation

64 galleries, 1403 albums, and 53,000 media assets

Task 4.4.1
(seconds)
4.4.2
(seconds)
Improvement
 Startup 53 4 93%
 Navigate to album after creation 38 <1 97%
 Navigate to album after sync 38 <1 97%
 Delete one album 38 <1 97%
 Delete ten albums 382 2.5 99%
 Add new role (w/ empty cache) 95 7.5 92%
 Edit role (w/ empty cache) 91 7 92%
 Save gallery setting 5 1 80%
 Activate move/copy dialog 119 8 93%
 Move/copy empty album 54 <1 98%

 

Bug fixes

Role/album relationships may disappear in multi-gallery scenarios – We thought we fixed this in 4.4.1, but apparently not. It’s been tough because we’ve never been able to reproduce it. In this version, we moved the role validation routine to run just once per application lifecycle (like we did with the other validation code) and we rewrote how it did the validation. We hope we finally nailed it.

Cannot upload a watermark image – We didn’t notice a breaking change when we updated to the latest version of the plupload widget back in 4.3.0. The new version changed a JavaScript namespace, preventing users from uploading a new watermark image on the Image Settings page. This has now been fixed.

A complete list of bug fixes and details about each one can be found in the 4.4.1 Fixed Defect Report.

How to apply this update

If your existing gallery is 4.X, upgrading is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

About the Author:

Founder and Lead Developer of Gallery Server

Leave A Comment