Hello.
I manage an archive of performance images for a small community orchestra. I've been using Zenphoto since I think 2007.
It currently contains 2,376 images in 105 albums.
I manage their website on a DreamHost shared hosting plan. Thse site is plain HTML except for the Zenphoto gallery. (Meaning Zenphoto is the only software using the database, and I installed Zenphoto manually.)
Although technically it works, performance has become intolerably slow.
Here's the link to the top level so you can see what I mean: https://www.parkwayconcertorchestra.org/Zenphoto/
I'm up to date with Zenphoto.
I have refreshed the database tables (from within the Zenphoto dashboard).
I have enabled the caching plugin.
I'm using the Basic theme.
Is there anything more I can do to improve performance?
Have I hit the limits of my hosting capabilities?
If so, is it possible to have multiple instances of Zenphoto, reducing the number of albums and images each instance has to manage?
The only warning I noticed when upgrading was that the albums table evidently isn't fully UTF-8, but I have no idea how to implement the recommended "repair."
If it makes any difference. I create new albums by uploading a folder of images manually via SFPT, them add details from within Zenphoto.
Thank you so much for any suggestions or insights you can offer.
PS, if you can tell me how to get the distracting light blue timestamp info off the album tile that would be most welcome as well.
Steve
Have I hit the limits of my hosting capabilities?
The number of albums and images does not sound that huge to already reach limits. Are all images cached? If you add via FTP they are likely discovered on first visit and then the image are resized to fit the theme. Depending on the px size of the image and the power of the server that can slow down:
Please review how image caching:
https://www.zenphoto.org/news/caching/
In any case disable random album thumbnails on your albums and pick a fixed one. If you have lots of uncached images that also slows down.
But it is also important how many visits/traffic you have.
Sadly I cannot view the Zenphoto site under the link you posted at all as that results with a "page not found" page.
My colleague noted to me that the actual Zenphoto albums are hidden unter the "Scrapbook" link.
I am not sure what cache plugin you enabled. Probably the cache manager but that is for generating image cache filesmanually. Other than that it does nothing. Please see the link noted above how image caching works.
I see that the execution of one album takes 10+ seconds. That is really slow.
You should enable the static_html_cache as that lowers the load of script execution. If even that does not help you might have some web server that is really slow in general. It might not even be webserver but could be the database server.
UTF8 is probably not really that much of an issue or showstopping especially if the text content is primarily English.
Of course you could install serveral Zenphoto installs on the same server but I would really not advice that. Causes extra work and does not lower the load on a possibly slow server at all.
Thank you for your time. Yes, cacheManager was the plugin I referenced. Yes, 10+ sec is what I experience as well, which is why I reached out! Interacting with the dashboard as a logged in user is equally sluggish (including 10-20 sec delay to log in our log out). I consulted DreamHost support before bothering you and they didn't indicate any issues with the database server. At the risk of sounding clueless, how do I enable the static_html_cache plugin? The support article you linked to says "Optionally there is also the included static_html_cache plugin" but I can't find that in the Plugins>All tab of the admin dashboard, nor does it show up as an option in the Cache section of the Overview page. Sorry to bother you with what should probably be obvious for a long-time user. It has always just worked wonderfully and effortlessly, so I have never really needed to get into it too deeply!
At the risk of sounding clueless, how do I enable the static_html_cache plugin? The support article you linked to says "Optionally there is also the included static_html_cache plugin" but I can't find that in the Plugins>All tab of the admin dashboard, nor does it show up as an option in the Cache section of the Overview page.
You should really find it on one of the pages of the plugins tabs. It should also appear on the sub selection "Admin".
But something is really slow on your server. We have nowhere as much images and albums but our site is on a normal hosting fpr under 10 euros, too. Nothing fancy like our own server or so.
With your guidance I found and enabled the static_html_cache plugin. I also noticed a series of debug log entries indicating an album was missing so I re-uploaded that album manually and now the debug log has stopped complaining. But performance hasn't improved, either while logged in as an admin or logged out. I have refreshed the database again from within the Zenphoto dashboard, and I have cleared the metadata. I can't think of what else to do. Setup indicated it couldn't verify that mod_rewrite was available but I'm convinced it is so I set that option in the theme and the gallery works, it's just painfully slow. I'm seeing 8-10 second delays in showing an album's thumbnails or moving to a new images with the "next" button. My .htaccess file's permissions are currently 0664. Is that appropriate? I couldn't find anything in the Zenphoto documentation that clearly states what rules should be in an .htaccess file. If I were to reach out to my host again, can you suggest what specifically I should ask them? Being only slightly conversant in databases and apache .htaccess rules I don't know the best language to use other than it's slow. Thank you for your time.
Looking at the source code of your site (the 2025-2026 season album) the static_html_cache plugin is not yet active. You would see a note in the source code at the very bottom if it is.
Setup indicated it couldn't verify that mod_rewrite was available but I'm convinced it is so I set that option in the theme and the gallery works, it's just painfully slow.
Setup cannot always 100% detect if it is working or not. If you know it is you can enabled it. It has no impact on speed.
My .htaccess file's permissions are currently 0664. Is that appropriate? I couldn't find anything in the Zenphoto documentation that clearly states what rules should be in an .htaccess file.
That is actually fine and what theserver sets. You can try to set it more tight. That applies to all permissions Setup suggests. On some servers tighter ones work and on others they don't.
Wrong permissions could technically be a reason for issues. These are the recommended ones for the other files: https://www.zenphoto.org/news/permissions-for-zenphoto-files-and-folders/
Another thing is if you can please look at your options table in the database. We had some users in the past where frequently duplicated option entries were generated although it should not be possible if the table is setup properly. There was some "unique" statement missing for some reason. If table that grows and grows it certainly can harm performance.
In general look at your table if it is maybe unexpectedly large or you see lots so duplicates.
Odd about the static_html_cache - it shows as active in my admin dashboard.
I have reviewed all the file and folder settings - 0644 for files, 0755 for folders.
As to the options table - you might be right but I don't know what to do. I see an "options" table weighing 4.6 KiB, and a "zp_options" table weighing 19.8 MiB with 254,000+ rows. Maybe that's the culprit. What do I do in phpMyAdmin? I have an option to drop or to empty. Is it safe to empty? I'm a total chicken when it comes to databases. After dealing with this, is there any way to prevent this happening in the future? I really do appreciate your time and help.
Is it safe to empty?
NO! You would literally kill your site. You should look if there are duplicates without changing anything yet. Look at the "name" column and sort that by name. Then see if there is more than one entry with the same "name". That should not be.
Regarding the cache: Probably my browser cache tricked me yesterdays. Now I see the note in the source.
The first album took 0.0002 secs from cache plus 3.1223 secs overhead that cannot be avoid. Problem is until the page is cached it needs to be processed and still will be slow. Also the cache updates itself after some time (you set on the option how often). So the first visitor getting the uncached page will have the same slowiness problem.
I still think it is the server somehow. Of coiurse the other part of the site being static HTML is unbeatable regarding speed literally. But the Zenphoto part is far too slow…
Do you have any visitor stats?
Then we possibly have found the issue here.
Please check if the table has these indices set correctly:
- PRIMARY id
- UNIQUE name(95), ownerid, theme(95)
The UNIQUE ones prevent that entries get duplicates.
That info should be listed at the bottom of the table page in phpmyadmin.
I wish I could share a screen capture with you. I'll do my best to describe what I see, but I'lll probably be clumsy about it.
In phpMyAdmin…
In the "Structure" tab of the "zp_options" table…
I see id, name, value, ownerid, theme, and creator
"id" has the key symbol.
I don't see anything anywhere that indicates "unique"
At the far right of each of these rows are links to change, drop, and "more". Clicking "more" does disclose the "unique" option, but I didn't try doing that. Additionally, underneath the listing of 6 rows, there are text links reading Browse, Change, Drop, Primary, Unique, Index, Spacial and Fulltext.
What does the "(95)" mean in your reply above? (As in "name(95)")?
Should I apply the "unique" setting to name, ownerid, and theme?
id and ownerid have attributes of unsigned. None of the other rows display an attribute.
Thank you for bearing with me here.
Thank you.
Here's a screen capture of what I see in the zp_options table
https://www.parkwayconcertorchestra.org/debug_zp/pcodata-zp_options.jpg
I now see there is only one entry in the Indexes portion.
If i make modifications, will this table clean itself up, or will I have to do something manually to clear the duplicates?
What does the "(95)" mean in your reply above? (As in "name(95)")?
That number refers to the character length of that column.
It seems the UNIQUE indices are indeed missing. You will have to add them manually via phpMyAdmin. Setup should have done. No idea why it doesn't on all host. Never encountered this myself so far.
No the table will sadly not clear itself, you sadly will have to remove the duplicates yourself manually… And before trying to set the UNIQUE indices as those would fail otherwise.
The entry with the highest value in the ID column is the latest of that option. Cumbersome it will be, yes…
It might work to create a backup via our database backup utility and then restoring it. But I have not tried that…
This topic I found quickly has some scripts but that might be a bit advanced:
https://forum.zenphoto.org/discussion/1410812/millions-of-records-in-the-options-table-duplicate-options-continuously-created
Besides you should always create a backup of the database before you perform any changes.
Oh no, please don't hate me.
Somehow I have two databases (probably from a near catastrophe several years ago, when I tried upgrading two many versions of Zenphoto at once, not in sequence).
I was inattentive as to which database is currently serving the gallery.
Here are two screen captures of the zp_options table for the correct database:
Browser tab:
https://www.parkwayconcertorchestra.org/debug_zp/zp_options-correct-browse.jpg
and the Structure tab:
https://www.parkwayconcertorchestra.org/debug_zp/zp_options-correct-structure.jpg
These look much more reasonable which is a relief, but it doesn't address the slow performance, does it?
I apologize sincerely for wasting your time by going down a wrong path.
I guess I should delete the old and obsolete table, but I don't imagine this has a bearing on my current issue.
No, problem, that happens ;-)
The structure looks good and has the correct indices. The table contents look good too. But you might only spot duplicates when you sort by name. But I doubt there are any as these table size seems reasonable.
And yes, unfortunately that now does not help with the performance issue…
Thank you for being good natured about the misleading information I provided previously. I'm embarrassed.
So now when I go to a page such as this:
https://www.parkwayconcertorchestra.org/zenphoto/2025-2026-Season/2025-12-14-East-Walpole/
I see this in a comment at the bottom of the page source (but not until after after refreshing the page):
Cached content of Wed, 17 Dec 2025 09:56:54 served by static_html_cache in 0.0002 seconds plus 3.1739 seconds unavoidable Zenphoto overhead.
I guess 3.1739 seconds is better than 8-9 seconds, but it feels like more than 3 seconds. Can I force the html cache plugin to cache the entire gallery, so does someone (me of course) have to manually load every album and every image within each album to generate the cache?
And can images be pre-cached across the gallery in addition to the HTML?
I see tools in the admin dashboard to purge HTLM and image cache, but will doing so force everything to be refreshed and pre-cached, or is requesting a page the only way to generate the cache?
Yes, that is much better. Although still not optimal. On our site albums - which are much smaller - have 0.0001 seconds plus 0.8842 seconds.
Can I force the html cache plugin to cache the entire gallery, so does someone (me of course) have to manually load every album and every image within each album to generate the cache?
Sadly you have to visit each page. There is no tool to pre-cache the HTML pages. Doing that would have to request every page one by one and that could overload servers. Most cache like this, also for other CMS, use this first visitor "caches" the pages principle.
So clearing the cache will just do that.
And can images be pre-cached across the gallery in addition to the HTML?
Yes, that is what the cache manager is for. Images are cached (= resized) on request by visitors, too. The cache manager provides a tool to pre-cache.
It has two ways you can set on the options: classic and cURL. You have to try which works better on your server. With lots of images and albums this can take hours. You may even need to try several times as it is quite some load on the server.
There is a third party plugin that hooks on this and worked better for some apparently. But it is already older and I have no idea if it still maintained and works properly.