Destructive Incorporated

While working to implement one of the most important features of desinc's site (the kiss photo gallery), I took a good look around to find the best program for the task. I had experience with Gallery v1 a while back before we lost a good chunk of server data, including the old kiss gallery. We also host a couple of user accounts who run gallery v1 on their pages so I decided to give it a look.

Gallery has 2 forks in its development. They are still developing Gallery v1, but they have a new branch, Gallery2. Reading over the differences, Gallery2 seemed like the clear choice for desinc.net. A robust, full-featured gallery with a clean and configurable theme system. But, more importantly, it was designed for a higher number of users and images because it is database driven rather than using flat files for its information storage.

So after a good bit of looking I chose to install Gallery2. It was a very quick installation and was almost completely browser-based. The only few things that were required pre-install were uploading and unpacking the files into a web accessible folder and creating a database for gallery2 to use. Once these tasks were done, the installation took maybe 5 minutes to fully configure and have an album created.

After the cakewalk of an installation, the whole user interface was very simple. There are tons of options, but most of them are easy to find under an appropriate administration menu, and most all of the options were fine right out of the box. Overall it took very little work to get the gallery looking about how I wanted it, of course if you are looking for a gallery that fits in very well with your current site the entire theme system is very easy to work with if you know some CSS. The only trouble I had at all was adding an image to the title area of the front page. I couldn't figure out via the admin menu, where I change both the title on the front page and where I might be able to ad an image in that area. After a while, I finally stumbled upon the area where you can change these settings. The front page settings are actually edited by editing the 'root' album. While it partially makes sense being placed where it was, I would much prefer and expect the main page's configuration to be in the administration area of the site.

The next task was to begin uploading images. Image uploading was a very easy proccess as well, with 9 upload options you are sure to find one that both meets your needs and your desires. I chose to use the java applet option for uploading because it seemed the easiest for what I wanted: to upload hundreds of images, all into one gallery, straight from a folder on my system. It was very quick, drag and drop, and had plenty of information about progress.

After I got the gallery up and running with images and albums, and was very pleased with the look and feel. While I was browsing around the features I also found another great one, a random thumbnail PHP script that you can ad to your 'other' web pages, much like you see on the bottom left of this page.

Right when I was beginning to think my first attempt with gallery software for the new site was a success, I happened to notice a couple problems, one of which was HUGE. The first thing I noticed was the gallery had a somewhat sluggish feeling to it, which the Gallery2 team equates to the difference between a flat-file (Gallery v1) and a database. A database must make a call to access the information, while version 1 did not need to make this call but would eventually become sluggish when the flat files became to large. I was willing to ignore this problem completely. Next, I turned on a server monitoring program (top, to be specific) and while simply browsing the gallery, a single user could use massive amounts of CPU time. Browsing the gallery I could use more than 90% of a single CPU constantly in our server MARIO (dual P3-733). This was simply unacceptable. To put it in perspective, you visiting this page used less than 5% of a single CPU on the same machine for about one second, all while making MORE database calls. I got Bob to browse from his house at the same time as me and just the two of us were starting to put a strain on the server and the load averages were becoming larger and larger.

At first I thought maybe there was some sort uncommon problem I was experiencing or a bug in the software. After a LOT of time reading their forums I found lots of people and hosting providers having the same issue and very little help from developers, who offer little to no support on the issue, and instead say things like "get better hardware" and insisting that their program is great. I lost almost all respect for the developers of gallery after reading their forum trying to solve my issue, and was unable to find a single helpful thread in their forum for the CPU load issues Gallery2 experiences. The problem is wide spread, affects all operating systems, and uses Apache resources. There is also no excess load from the database, which solidly puts the blame on Gallery2's code.

I was forced to cancel my plan to use Gallery2 as the software for this site. I now use a Drupal embedded PHP gallery, acidfree, which is using no more CPU than any other page load on the entire website, is still quite clean, and has the same random image ability. So far I am quite happy with this system. I have also found that the Drupal community is FAR more responsive and handle problems like these in a FAR more professional manner.

For the record, I did NOT install Gallery2 embedded into Drupal, which I have read can be even worse on both CPU time and slow page loads. After this experience I also looked into how much CPU the current gallery v1 we host for a friend uses, and found it to be quite excessive as well, though quite a bit less than Gallery2 on our system.