The simpler media website CMS
I have now converted my third image collection from the old Menalto Gallery 2 (not supported now for many years but still an excellent database if you don't have to conform with PHP higher than 5.4) as I want to have everything running with PHP 7.2 or higher. I chose Zenphoto over Piwigo because it is folder based.
The the collection has a lot of albums: a collection of documents - each folder has only 2 or 3 pics - 6000 odd folders, 18000 odd pics.
I notice that the admin Albums is very slow indeed although the front side runs quickly enough.
I see you have had a comment or two about this in the past.
I had a look and it seems to me the slowness is caused by the collection having a lot of albums and the fact that each time the Albums page is called up in admin it compiles a complete listing of folders for the 'move' function.
On this system the topmost album produces an html page with something like 17 000 lines, almost all of that the 'move' options.
Would it be possible to have the 'move' function only to be called when necessary?
This, I think, would speed up the page no end, and in my experience of these databases 'move' is only occasionally required. I am not sure how it could be done - probably easy to leave it off the Admin Albums page, but how to make it available when needed?
Just a thought,
Richard Ball
Comments
Do you really have all 17,000 albums on the top level? That's of course a lot. We actually would recommend to organize more in sub folders.
I think the sorting display is not the problem here. We may consider a paginated display for albums for some time later. However to be able to move and sort on all levels via drag and drop this will not change
A few things to speed up:
1) In case the 17,000 albums you mention also include sub albums limit the level on the albums admin page to one level (top right selector)
2) Also disable the album thumbs ("show thumb standin") and/or set a fixed album thumb to all albums as otherwise ZP will pick one randomly and if not everything is cached this will cause several image processing actions (see our site's user guide for "caching"). Other than other systems like Piwigo ZP does not work with fixed image sizes that are created on upload.
3) Pre-cache images using the cacheManager (this includes backend sizes).
No, there are not 17 000 albums at top level.
There are 6000 or so albums altogether - in the top level there are about 27 albums - with 6000 further albums below them - down to about 3 or 4 levels below.
The Admin album first level page is not a problem, it snaps up with no delay - it has no 'move' option on it.
But any album below that, when you call it up under Admin, goes through the whole database to provide the options for the 'move' option menu and from takes about 10 seconds for anything to appear and about 14 seconds for the page to complete loading.
If you look at the 'view page source' you find that all the menu options for the 'move' or 'copy' option have been calculated and printed to the html page, making a total of about 7000 lines of html for that page.
And the more albums you have, the slower any of the Admin album pages below the top level are going to load.
The page/form I am referring to is the Edit Album: page for a single album, not the listing of albums or subalbums although those are pretty slow too.
Thanks,
Richard
Okay, thanks for explaining. I did indeed misunderstand. We'll review that.
I see what you mean. Quite some backend reworking is on the list for the "next major" release and this will surely be part of it.
Any idea how long to the 'next major release' ?
No, sorry, won't tell any dates as I most certainly will not be able to keep that.
there any solution? i also maintain around 4000-5000 albums and around 14000 - 15000 image
Several ways as often listed:
Possibly use and try these in combination.
And solution if nothing of that helps: Get a faster server that can hande the amount of images necessary