I have two instance of Zenphoto running on a pretty standard shared hosting account, and have has issue with high CPU usage and MySQL timeouts.

The 'small' gallery has 4,911 images in 250 folders, the big gallery has 13,357 images in 288 albums.

Some pages that give me concern are:

• a custom creation of mine that shows 12 random images, using getRandomImages() to get each image: 43 DB hits.
• index page showing all albums, with 24 per page: 50 DB hits.
• main page with 4 random images and 20 odd dynamic albums: 44 DB hits.
• album page with 32 images: 40 DB hits.

On the other hand, I have a custom page that queries the DB directly to get the most recently uploaded images. It only makes 6 DB hits (most of them for Zenphoto background stuff).

Is there a reason why the number of DB hits for most 'standard' pages is so massive? It seems pages query the album to get the image IDs, then it queries each image individually. Is the just how Zenphoto works?

Does anyone else out there run such massive galleries? I enabled the 'Static HTML Cache' plugin a few days ago, but have no real stats on how it has improved performance so far.

We have some users with pretty big pages. Note that Zenphoto is file system based so it needs to cache and generate the sized and cached image version on first discovery. It also gets the exif data from these images if some exists. So that would explain the db hits as these info is stored in the database. After that is done it should be less active.

What also might help is to set the album thumbs to a fixed one instead of random selection.

Also the randomimages of course first need to get all images to make a random selection.

Thanks for that - most of my albums are set to use a random selection of thumbnails.

As an experiment I have tweaked my main page to pull content directly from the DB, showing 4 random images (using a custom algorithm) and dynamic albums using static thumbnails - down to about 14 DB hits from 44.

I guess one one of speeding up the site would be to create more custom PHP pages that hit the DB directly, avoiding the directory traversal. (with 'normal' pages will in the background for my own use, to populate the DB when I add new images). I should tweak my current hacks to fit the plugin architecture - at the moment they are just robust enough to handle upgrades to the Zenphoto core files.

wongm:

Similar to your case, I also write my own function to get 16 random images on index page.

And, don't use the Album random thumbnail selection, it is very high cost function if got a lot album. For a parent album, zenphoto loop the sub album one by one (get all images in an album and shuffle it) to get the random thumbnail.

Quote:And, don't use the Album random thumbnail selection, it is very high cost function if got a lot album. For a parent album, zenphoto loop the sub album one by one (get all images in an album and shuffle it) to get the random thumbnail.
This is not quite what happens. First, if the album is not empty of images only those images contained in the album are considered. If there are no images, then the subalbums are considered randomly until one with a thumbnail is found. That thumbnail is then selected for the parent album. (This is a simplification, things such as visibility, image priority over "video" objects, etc. are also applied.)

@wongm:
i have 3 installations with zenphoto:

1. http://gallery.southdreamz.com - 1, 50, 000 photos
2. http://spicy.southdreamz.com - 25, 000 photos
3. http://album.mirchiwoods.com - 50, 000 photos

My experience is:

1. I have enabled static cache
2. I'm not using latest or random photos/album on every page.
3. Disabled the zenphoto powered search and enabled google powered search
4. related albums/photos, i'm using linkwithin powered code.
5. I don't have more than 100 images in each album.
6. Large albums have been spited into more sub albums.
7. Index page is always static(Yes, it is pure HTML page).
8. Feeds are cached and redirected to feedburner.
9. Recent album list is generated from feedbuner.
10. i never uploaded the image that more than 100KB.

and some custom setting(now, i can't remember) more...
but still my system needs optimization, because it is running in SHARED SERVER. Please share if there is any idea you got.

Quote:This is not quite what happens. First, if the album is not empty of images only those images contained in the album are considered. If there are no images, then the subalbums are considered randomly until one with a thumbnail is found. That thumbnail is then selected for the parent album. (This is a simplification, things such as visibility, image priority over "video" objects, etc. are also applied.)
Just review the code, the number of loop is related to depth of the albums but not the number of subalbums. Sorry for the misleading.

Just to note: Our RSS feeds are also cached as static xml files since 1.2.7.

[i]3. Disabled the zenphoto powered search and enabled google powered search[/i]

How does one do that?

@special-k: You need get google custom search code, go to themes files(index.php, album.php, image.php) and find and replace form.

I thought I would tack this onto here as it's all about performance.

What I believe would help performance (for front end users) would be to minify the CSS and JS and then combine (if possible) the CSS and JS and then gzip (.gz) the resulting files. At the same time the html could be gziped as well.

All of this could then be stored in cache and the site would be faster uploading as it could be and there would be far less of a strain on the backend.

Using the new zpGalleriffic (what a great theme that is) I have 9 JS and 3 CSS. This is a rough estimate but with only one (maybe two) request for JS and one for CSS + a savings of approx 56 kbytes, it all helps ....

Anyways, it's just a thought and there a couple of third party software packages that can help in this area.

ZP 1.2.9 is just a great upgrade. Thanks for your time and dedication to this worthy gallery.

CSS and JS are generally not going to be your performance bottlenecks -- most browsers will cache them after after the first request, so while you can certainly optimize them by condensing them into a single JS file and a single CSS file, users will only notice it on the first page they visit. Google for JS and CSS compressors, and you'll find a number of online and offline tools for reducing their sizes.

I haven't had any experience with the Static HTML Cache plugin, but generating static pages from non-dynamic and often-hit pages is going to give you the most best performance/load boost.

Is there a way to prevent directory traversal from happening unless you are a logged in user? (digging through the code would be easiest way for me to work it out) And if you can, will it drop CPU usage to some degree?

In most cases when you upload new images you are going to set captions anyway, which will lead to the new items being found and added to the DB.

1. Yes, if you use the static html cache because then the static html files are used.

2. But before you can add captions Zenphoto will need to discover then new items on the filesystem so it needs to compare what is there and what might not be anmore. Remember you can just use ftp to upload your files instead of using the backend to upload.