Keywords and MultiAlbum Function: Does it slow the presentation Keywords and MultiAlbum Function: Does it slow the presentation
 

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

Keywords and MultiAlbum Function: Does it slow the presentation

Started by cgc0202, May 30, 2006, 11:40:52 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

cgc0202

Hi,

This is a different aspect of the application of "Keywords and MultiAlbum Function", so I decided to have it as a separate thread. I have several galleries, and I noticed that the gallery where I started to apply the use of "Keywords and MultiAlbum Function" was markedly slower than the other galleries I have created so far.  I tried to consider various possibilities, like clearing the cache, turning off and restarting the computer and varying the time of day (to account for internet traffic and cable internet connection speeds), etc.  to try to eliminate artifacts but it remained slow.  I just timed it before writing this post and it ranges from a few seconds to as long as 30 seconds before a page would appear.

I decided to compare it to another related gallery where the same phtos were derived from (please see note below***). I alternated the clicking of categories, albums or home, from one gallery to another -- to compensate for variations in internet connections with time -- the one where "Keywords and MultiAlbum Function" was implemented remained markedly and consistently slower most of the time.  In both cases there were only a few categories and albums, so that would not have been an issue. 

In fact, I have an older Gallery with more photos (748 files) and categories and albums than the aforementioned two, and this other gallery -- where  "Keywords and MultiAlbum Function" has not been implemented yet  -- is consitently faster than the one where  "Keywords and MultiAlbum Function" was applied.

Not all the photos have been tagged yet in the Gallery where "Keywords and MultiAlbum Function" is being implemented, as I am still learning its function and how to go about addressing the related issues raised in "MultiAlbum Function: Bug, incorrect use or actual status of script?"

http://forum.coppermine-gallery.net/index.php?topic=32068.0

I wonder if the speed of presentation would slow further -- in the  Gallery where "Keywords and MultiAlbum Function" is being implemented --  once all the photos and albums are properly tagged, and there are tens of thousands of photos, as well as categories and albums, instead of the current initial state of a few hundred  photos and less than a hundred of categories and albums (489 files in 5 albums and 48 categories).

Speed of presentation of a page is critical to keeping the patience of a visitor to a tolerable level before they decide to move on, if the process is too slow.  I am not sure how the  "Keywords and MultiAlbum Function" really works, but if there is an inherent tendency to cause the presentation to slow down, then it is better not to use this feature.

While it is in itself cumbersome to prepare, it would be better to create multiple galleries, focusing on specific presentation of the photos, provided the speed is much faster. There are other current limitations and disadvantages  associated with "multiple galleries" but it seems much faster in presentation from my current limited experience in implementing it.

cgc0202

***Related Galleries

CPG Gallery I:  No keyword tags in albums and photos (i.e., multialbum feature not implemented)

The photos used here were based from Creative Commons photos.  However, the photos were very large files, 200KB to 2MB files and of different sizes.  I used a transition CPG gallery (CPG Gallery I) to create photos of the same maximum width/height, and the process also dramatically reduced the file sizes of each photo that are clear enough for internet presentation.

This gallery is intended also as a place where contributors may submit photos, subject to approval. User submission was simulated in the upload of photos to this gallery so that the photos were stored in the "userpics" directory.

CPG Gallery II:  "Keywords and MultiAlbum Function" implemented (in limited number of photos and albums, so far)

FTP was used to transfer the re-sized photos from CPG Gallery I  to this other gallery (CPG Gallery II) where "Keywords and MultiAlbum Function" is being implemented.  "Batch upload" was used to transfer the photos to specific album.  There is no user album in this gallery (since photos are planned to be submitted through CPG Gallery I).

As it turned out, there are more photos in CPG Gallery I (530 files in 10 albums and 6 categories ) than CPG Gallery II (489 files in 5 albums and 48 categories) because there were files uploaded in CPG Gallery I that did not meet the minimum re-size requirement, so that no intermediate (re-sized) photos were created for these smaller photos.  Note also that the file sizes of photos were significantly larger in CPG Gallery I (200KB and 2MB) compared to CPG Gallery II (~50KB to 200KB), so the individual presentation of the large photos should be slower in CPG Gallery I.

As outlined above, the presentation of photos in CPG Gallery I was significantly and consistently much faster than  in CPG Gallery II. As discussed above too, another CPG Gallery with more photos and galleries was even faster than CPG Gallery II.

Paver

When you say that "Keywords and MultiAlbum Function" was implemented, do you mean you set keywords on certain albums?  And conversely, when it was not implemented, you had no albums with keywords set?

As I mentioned in your other thread, it seems to me that the current keyword system is very inefficient for large numbers of keywords & photos.  I personally want to use effective keywords and so have considered what to do to overhaul the keyword system.  But I don't know when that will be, or how effective it will be compared to what it is now.

cgc0202

Hi Paver,
Quote from: Paver on May 31, 2006, 12:00:17 AM
When you say that "Keywords and MultiAlbum Function" was implemented, do you mean you set keywords on certain albums?  And conversely, when it was not implemented, you had no albums with keywords set?
"Implemented" means following the manual instructions, photos were assigned multiple keywords, while an album has a single keyword, in the keyword section.

"Not implemented": no key words were assigned in either the photos and the albums.

Quote from: Paver on May 31, 2006, 12:00:17 AM
As I mentioned in your other thread, it seems to me that the current keyword system is very inefficient for large numbers of keywords & photos.  I personally want to use effective keywords and so have considered what to do to overhaul the keyword system.  But I don't know when that will be, or how effective it will be compared to what it is now.

In regard this post, I am not too sure whether the "Multialbum-keyword" process is really causing the slowing of the gallery. I am in the process of exploring other factors that would cause the slowing process. This is superimposed over an update procedure and that might have complicated the process, as I might have not done the update properly.

cgc0202

Paver

Quote from: cgc0202 on May 31, 2006, 03:21:48 AM
In regard this post, I am not too sure whether the "Multialbum-keyword" process is really causing the slowing of the gallery. I am in the process of exploring other factors that would cause the slowing process. This is superimposed over an update procedure and that might have complicated the process, as I might have not done the update properly.

As I think about this more in regards to your observations, I don't think the keywords system would cause such a major slowdown as you observe.  I believe (but haven't tested) that the keyword system is inefficient and clumsy as it is now implemented, but I don't think it's necessarily that slow.

So your further testing will be useful to investigate this.