Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
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
Comments
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!
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 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.
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.
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?
admin_lastvisit (19,000+ rows)
admin_lastvisit_timeframe (similar)
Excessive_URL_count - loads of rows
words_to_die_on - loads of rows
Those seem to be the most repeated. My eyes got tired after a while but there are probably other duplicates.
Then we possibly have found the issue here.
Please check if the table has these indices set correctly:
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.
The list of indices should be below the table listing.
We don't allow image uploads here but you can upload an image somewhere else and add a link 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?
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.
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.
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.
Got it. I'll do the image caching album-by-album as the plugin suggests, and won't worry about more than the last season or two.
So last (I hope) question: even with the html cache enabled, what accounts for "unavoidable Zenphoto overhead," and why do I see 3+ seconds when you see under a second on your own gallery? What's the bottleneck? Is it a server thing or is it a consequence of lots of albums and images?
I upgraded my PHP version to 8.5 today and didn't notice any difference, good or bad.
"unavoidable Zenphoto overhead," is some processing as Zenphoto needs to check a few things to process. It is not 100% plain static. For example it needs to checking if a page is already cached, needs to be created and/or if the cache time has exceeded so it should be renewed or created. Also some publish and procetion checks need to be excecute always so no one gets anything to see unwantedly.
It is really hard to say. Mostly it is a combination of a server not able to handle the amount of images and albums for some reason. We have some users here with really huge sites.
8.5 should work but I have to note we haven't tested it at all with that as we don't have access to it yet. We test with 8.4 primarily currently.
Well, thank you very much for your patience and responsiveness.
I don't suppose a database backup and restore would provide any benefit.
"Installation Information" indicates 23 active filters - is that reasonable?
I guess now I either live with 3+ seconds even for cached pages, or I badger DreamHost again. In short, everything you can think of from your end as Zenphoto developers has been explored, right?
For what it's worth, in my limited experience it seems to do what it's supposed to on PHP 8.5.
Thanks again for your time and all your advice.
Probably not since you restore the same again.
Yes, filters means hooks where plugins hook into to provide functionality or just add css or js files necessary. Our site has 60 filters active.
Of course to disable plugins you don't need is always a good idea.
I at least have currently no other idea to help sadly. It looks from timeline tools in browsers that the server takes those seconds to respond.
At least onec it is cached it seems to be acceptable…
I did pair down the plugins to only 5.
That's a potentially helpful talking point for when I reach out to the host. I can also say that the images and albums I have aren't out of line with what other Zenphoto users have. I don't know if I'm able ot allocate more PHP memory - I don't even know what I have now - but tht probably wouldn't have a bearing on page load speed. And maybe I'll be told this level of server response is the best I can expect from my plan.
I do so appreciate your help - and of course Zenphoto!
How much memory do you have? Image resizing can slow down if not already resized/cached as it is as already mentioned a hungry task.
Your host really should be able to tell you something… Of course big hosts like Dreamhost - which I don't know from personal experience - can sometimes be a bit unflexible in all regards.
I don't know how much memory my shared hosting allocates, but that's something I will ask. I think I pre-cached all the images from the most recent album (2026-2026 season) and I don't see a remarkable improvement. If the issue turns out to be server response time to render even cached pages, memory wouldn't make a difference, would it?
As far as flexibility goes, I don't imagine there's much I can ask for on a relatively inexpensive shared hosting plan, but I have stayed with DreamHost for years because their support has always been responsive and helpful. (Not as helpful as YOU, but you set a high standard!) They don't always have a magic answer, but they always respond carefully and thoughtfully.
You can see a general, maybe not 100% accurat number right on the admin overview page among other info. There is also a utility named "php info" that will list the PHP configuration details (using a standard php function for that).
Well, memory of course generally can have performane input.
Of course, that is understandable, they cannot know every tool anyone uses on their server. But they should be able to tell what might cause this delay.
Resolution! DreamHost Support noticed that my web server and the mySQL server were in different data centers. Today they migrated the database to the same data center as the web server and performance has been transformed. I'm so grateful for the time you spent with me, so I could intelligently articulate the issue to my host, who was then able to consolidate the two servers into the same physical location. It took a long time to unravel this, but now the performance difference is huge. Thank you again.
Great news, glad they managed to find the bottleneck! Feels good when I click around a bit. Nevertheles all the measures we tried/did were not for nothing!
Right. I hope maybe some day my episode will help you help some other user! Maybe this was an obscure edge case, maybe not. I started my hosting plan with DreamHost long before I ever had any sites with mySQL dependencies, so that probably accounts for why the web and database hosting servers wound up in different data centers.