Hi,
I'm still dealing with a lot of pictures here, but it looks like everything is working as expected. One thing that came do my attention is the cache feature of the PersistentObject() class.
There should be a check when reading albums or images from the database. Having a memory cache may be nice if you have 20 or 30 albums/pictures, but if you hit something like this:
mysql> select count(1) from zp_albums;
+----------+
| count(1) |
+----------+
| 13543 |
+----------+
1 row in set (0.02 sec)
mysql>
The memory cache brakes nearly every memory boundaries ...
Thanks!
KR,
Grimeton
Comments
Generally speaking you have to have a serve with adequate resources for the site you are trying to host. This is really a basic law of software.
http://www.zenphoto.org/support/topic.php?id=9515
It caches the thumbnails, but takes a long time to do it.
I think the way the software is structured of when it CREATES the thumbnail could be better considered.
Maybe selecting some albums not not display a random thumbnail of or something.
Id also like to point out that selecting just the home page of the albums shouldnt just go and render the thumbnails for every image and every picture in the whole site! I personally think it should be done at a lower level, when it gets to say the actual album with the images in it.... sure if you have 50000 images in that sub album, it might make life annoying, and a persistent cache would be good, but to start to do thumbnails at the home page, unless there is some very good reason im overlooking, defies login IMHO.
I think a persistent cache of images would be good, and a setting that can be customised and controled.
I also think that where the thumbnails are generated should also be reconsidered.
Just my 2 (unwanted) cents
That said, if you have quite a lot images they are naturally not cached as thumbs etc. therefore. So when randomly an album thumb is selected it takes some time to create that especially if the image are in bigger sizes. But it even then does not create all but the one randomly selected thumb. Of couse if you have dozens of albums per pages that multiplies.
Anyway, you can disable the random album thumb on each album's admin page by selecting a specific image.
The image cache is persistent. Once an image is cached and you did not change image size options it will not be cached again. Again please see the troubleshoot how image retrieval works on Zenphoto.
thanks for the answers. I debugged the stuff, because it was suspicious that indexing 200.000 files worked and after I stopped the process and restarted it, it coredumped. I changed the memory limit to 4096M to see what happens and I saw a nearly 2gb "big" php process.
The problem is, that at the moment Gallery() is in "instanced", I can see this in the MySQL query logs:
`
178 Connect zenp@localhost on
178 Init DB zenphoto
178 Query SET NAMES 'utf8'
178 Query SET SESSION sql_mode=""
178 Query SELECT
name
,value
FROMzp_options
WHEREownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='imagick_filter' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='magick_font_size' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='zenphoto_captcha_length' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='zenphoto_captcha_key' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='zenphoto_captcha_string' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='strong_hash' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='extra_auth_hash_text' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='min_password_lenght' ANDownerid
=0178 Query SELECT * FROM
zp_options
WHEREname
='password_pattern' ANDownerid
=0178 Query SELECT * FROM
zp_administrators
WHEREvalid
=1 ORDER BYrights
DESC,id
LIMIT 1178 Query SELECT * FROM
zp_administrators
ORDER BYrights
DESC,id
178 Query SELECT * FROM
zp_administrators
WHEREpass
='682186855e723a906bd7b7e86b1e9b4ecac3a682' ANDvalid
=1 LIMIT 1178 Query SELECT * FROM
zp_administrators
WHEREuser
= 'admin' ANDvalid
= '1' LIMIT 1178 Query SELECT * FROM
zp_images
WHEREid
>5 ANDmtime
=0 ORDER BYid
LIMIT 7178 Query SELECT
folder
FROMzp_albums
WHEREid
="2"178 Query SELECT * FROM
zp_albums
`
Intersting is the last line which is generated from a function in classes.php. The constructor of PersistentObject() calls the "load()" method which initializes the "in memory cache" which then sends the last line to the sql database.
I just figured that out by setting "LIMIT 1","LIMIT 2" at the end of the sql queries so that I got a clue which function it is.
The only way to "solve" this problem was to patch the Constructor and force $this->use_cache to be NULL.
That's why asked for some kind of limit that's like:
`
if (!$rows_on_table_albums > $config_variable_from_zp-config_php) {
// do caching stuff here
}
`
KR,
Grimeton
Update: My collegue already did some work on this in the dev nightly build. Please give it a try.
just did a fresh install of a nightly build (7757) and tried to get an instace of Gallery() which worked. But the moment you call Gallery::getAlbums() you're screwed again and the system does a
`select * from zp_albums;`
again, which should be like:
`select * from zp_albums where zp_albums.parentid is NULL;`
Then only the subalbums are returned, which is the expected behaviour, I guess.
I just signed up on the Trac page and will submit some patches to make the caching and indexing script for cron available to the public
I guess that was the way open sauce^Z^Z^Z^Zource was ment to work.
KR,
Grimeton
`
KR,
Grimeton