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

I guess I really do not understand your post. Are you having problems with the MySQL count function? Not much we can do about that.

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.

I have to say that im having a very similar issue in this post

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

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!

Zenphoto does not preliminary create thumbnails for the whole site if you visit the home page (which you would know if you have read on the troubleshooting).

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.

Hi,

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 [code]name[/code], [code]value[/code] FROM [code]zp_options[/code] WHERE [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='imagick_filter' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='magick_font_size' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='zenphoto_captcha_length' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='zenphoto_captcha_key' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='zenphoto_captcha_string' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='strong_hash' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='extra_auth_hash_text' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='min_password_lenght' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_options[/code] WHERE [code]name[/code]='password_pattern' AND [code]ownerid[/code]=0
178 Query SELECT * FROM [code]zp_administrators[/code] WHERE [code]valid[/code]=1 ORDER BY [code]rights[/code] DESC, [code]id[/code] LIMIT 1
178 Query SELECT * FROM [code]zp_administrators[/code] ORDER BY [code]rights[/code] DESC, [code]id[/code]
178 Query SELECT * FROM [code]zp_administrators[/code] WHERE [code]pass[/code]='682186855e723a906bd7b7e86b1e9b4ecac3a682' AND [code]valid[/code]=1 LIMIT 1
178 Query SELECT * FROM [code]zp_administrators[/code] WHERE [code]user[/code] = 'admin' AND [code]valid[/code] = '1' LIMIT 1
178 Query SELECT * FROM [code]zp_images[/code] WHERE [code]id[/code]>5 AND [code]mtime[/code]=0 ORDER BY [code]id[/code] LIMIT 7
178 Query SELECT [code]folder[/code] FROM [code]zp_albums[/code] WHERE [code]id[/code]="2"
178 Query SELECT * FROM [code]zp_albums[/code]
`
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

Ok, thanks. Now we get an idea what you mean. Howerver, I will leave this to my collegue who is more familiar with the exact internals of these all.

Update: My collegue already did some work on this in the dev nightly build. Please give it a try.

Hi,

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

`

I don't suppose you can point out where this query is? I do not see it in the getSubalbums() path.

I just checked out the latest trunk from svn and it seems to be working. It's now using "IS NULL" as where clause so - I think - it works.



KR,

Grimeton