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.
What's the bottleneck? Is it a server thing or is it a consequence of lots of albums and images?
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.
upgraded my PHP version to 8.5 today
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.
I don't suppose a database backup and restore would provide any benefit.
Probably not since you restore the same again.
"Installation Information" indicates 23 active filters - is that reasonable?
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.
In short, everything you can think of from your end as Zenphoto developers has been explored, right?
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.
It looks from timeline tools in browsers that the server takes those seconds to respond.
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.
don't know how much memory my shared hosting allocates,
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).
If the issue turns out to be server response time to render even cached pages, memory wouldn't make a difference, would it?
Well, memory of course generally can have performane input.
They don't always have a magic answer, but they always respond carefully and thoughtfully.
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.
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.