Hi,

i have now 4042 images in my zenphoto database, all images in one album. The problem is, that it gets really slow now. I have a list of Tags and some random-images on my startpage - and it needs about 10 Sec to display the page (!!). The single-image page is also slow - but not as slow as the startpage (index.php). I run it on a vserver and also tried it on my dedicated server at home. Both are very slow.

When i had less pictures in my db, it was much faster - can you tell me if 4000 images is too much or do i have to split them up in different albums? Or is there a fix available when i have this much images? I had a look at the performance-hacks and implemented the second one but it changed nothing it seems. I havent tried the other hacks because i dont know what eAccellerator is and how to install it.

Maybe somebody of you know what to do in my case and if the eAccellerator-Hacks will solve my problem?

Thanks a lot!

I have not tried these hacks so I can't say anything to that. There is generally no limit of images in Zenphoto, but dividing such large albums is recommended. Please read this troubleshooting entry:
http://www.zenphoto.org/2008/08/troubleshooting-zenphoto/#23

Regarding the there mentioned static-html-cache-plugin, you should use the nightly/svn version since we recently corrected some bugs in that plugin.

Not to hijack this thread but I also am having performance issues, instead of performance issue on the viewing end it's on the administration end.

I have about 8000+ photos and zenphoto has no issues with this. It's that the majority of the photos are in one album with many subalbums (aka many folders and subfolders).

From looking over the code there are 2 areas where having many subalbums/subfolders creates performance issues:

Currently I have 223 folders. The function genAlbumUploadList which looks like recursively goes through the entire zenphoto album folder structure just slows to a crawl. Organizationally I want to keep these in one album instead of splitting them into separate albums. I understand that this function is used to allow the convenience of being able to move subalbums and photos anywhere in the album/gallery is an excellent reason for this. However doing a filesystem recursive directory listing each time is quite expensive. I also understand that this makes the most sense since relying on the database for folder information while faster may be prone to errors (e.g. filesystem folder moves and deletions).

To a lesser extent the function printAlbumEditForm section where it generates the thumbnail dropdown, while allowing you to disable the photos in the thumbnail dropdown, also has the same issue as genAlbumUploadList where at its worst has to generate the entire album list of photo names (if you were at the very top level).

If I edit the code and disable both the folder generation function and the thumbnail generation section, the time it takes to move from album/subalbum to another goes from 45 seconds to 5 seconds.

I recognize the trade-offs but thought I'd throw out the scalability issue of these 2 areas for others that may have issues in these areas.

Thanks!

It is hard to see how recursing one album with 223 subalbum folders could be a time consuming filesystem issue, at least for the albums. That would be just 224 folder searches.

Have you tried disabling just the thumbnail generation? Most likely that is the cause of your slowdown.

For me, I won't access the album edit page at admin->edit, mostly I access the album edit form front end admin panel....

In a album, I have 206 sub-album & 3100 photo, my zenphoto is on a VPS. I have just test the time for comment some functions.
original: 1m10s
disable thumbnail selection: 20s
disalbe thumbnail selection & sub-album page: 4s
disalbe thumbnail selection & sub-album page & genAlbumUploadList: 2s

My suggestiion is:
1. thumbnail selection list only take direct child photo/direct subalbum thumbnail.
2. the sub-album/photo edit tab page load at click the tab(current is load first & hide it)

Sorry, but i have to switch back to my topic

I divided the images in three albums now - but the speed isnt much better. Especially the index.php is extremely slow. It takes up to ten seconds to load it!

Sadly tummblr.com is offline. Seems like a domaingrabber has taken over the site. Can somebody upload the html-caching plugins to zenphoto.org please?

There is a static html cache plugin included in zenphoto 1.2.1 (better use the nightly because of some bug fixes). All other known performance hacks are to be found here: http://www.zenphoto.org/2008/06/performance-hacks/

Two trouble tickets have been posted on these performance issues.

Hey acrylian,

thanks a lot for your help! I updated to 1.2.1 (nightly build from last friday) and activated the html_cache plugin. It works much quicker now! Great

But i found two bugs: I modified the full-image.php a little so it fits my template. When i click on the image, the full-image.php is loaded. But with the caching on - theres always the same full-image (not the one i clicked on). Seems like just one version of the full-image.php is cached.

And the other bug is quite similar. I made an extra page where users can download the images for free or order them in high resolution. Because i need to know which image they want to download i give the name to the page by url-parameters. The problem is the same - its always the same page which is loaded - but it must be different for every image. Seems like url-parameters are not cached?

To see the effect you can take a look here:

http://bilder.n3po.com/Fotos/Zebraspinne-Details-Koerper.jpg.html

That plugin was of course created for "normal" Zenphoto/Zenpage use and not all possible site modification..:-)
But if that link with the parameters is on the page when it is cached it should be saved with the html. But if that is dynamically created each time via session for example that will not work. The cache is a static one. What is cached is cached. In that case you will probably need another solution.

Actually the full-image.php should not be cached also. We will take a look, maybe that needs to be excluded specifically.

You are using full-image.php in a way not intended. If you just want a custom page with a larger image you should do just that--create a new page script, use the custom sized image functions and point a link to that page instead of the full image script.

Ok, thanks.

Regarding the link to the order/download page: It is a static link - i just pass the image-filename by the url. Is it possible the caching treats /order?id=1 and /order?id=2 as the same page?

Isnt it possible to manage the caching and include / exclude specific pages in the static_cache.php? Would be a great feature.

And a final question: Do you cache /search/tags/ ?

Thanks for your help! You do a fantastic job!

Just to explain how the static cache works: If you load a page the first time it is generated dynamically, after that the cache saves that as a plain html page. This means if your link is generated it gets also cached on that html page.

It is not possible to exclude pages unless you change the code to do that.

Search/tags pages are not cached due to their absolut dynamic nature.