Summary | Statically cache images and galleries |
Queue | Ansel |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | mrubinsk (at) horde (dot) org |
Requester | duck (at) obala (dot) net |
Created | 06/26/2008 (6195 days ago) |
Due | |
Updated | 07/05/2008 (6186 days ago) |
Assigned | 06/26/2008 (6195 days ago) |
Resolved | 07/05/2008 (6186 days ago) |
Milestone | |
Patch | No |
State ⇒ Resolved
to call it, it would serve no purpose since the only logical place to
use it would be at the end of script execution, when all objects are
destroyed anyway. The article mentioned refers to removing circular
references when objects go out of scope and are unused - these are not
circular references nor do we know for sure when we want to destroy
them, other then at request shutdown.
http://cvs.horde.org/diff.php/ansel/lib/Ansel.php?r1=1.458&r2=1.459&ty=u
method anywhere in the code. Where is this intended to be called?
method anywhere in the code. Where is this intended to be called?
State ⇒ Feedback
method anywhere in the code. Where is this intended to be called?
State ⇒ Resolved
http://cvs.horde.org/diff.php/ansel/lib/Ansel.php?r1=1.452&r2=1.453&ty=u
http://schlitt.info/applications/blog/index.php?/archives/605-Hierarchical-caching.html and adding a local-memory cache? That way the cache could transparently handle things that should be returned from local memory, then fall back to memcache (if enabled), then fall back
to
disk/sql.
for Horde 4. See
Ticket: 6996New Attachment: Ansel-static.diff
http://schlitt.info/applications/blog/index.php?/archives/605-Hierarchical-caching.html and adding a local-memory cache? That way the cache could transparently handle things that should be returned from local memory, then fall back to memcache (if enabled), then fall back to
disk/sql.
Assigned to Michael Rubinsky
Summary ⇒ Statically cache images and galleries
State ⇒ Assigned
still be turned off in the config if that is desired and l want to
look and see what code paths would lead to the images that are pulled
from getImages() to be accessed again on the same page....I'd hate to
always cache the image object on every gallery page load...that is a
lot of images, with the image data already loaded, to keep in memory.
times on the same page for the same gallery.
State ⇒ Feedback
on the cache by a user that is requesting a particular gallery for the
first time if another user already requested it, your patch can end up
having to retrieve (and store in memory) the same gallery from the DB
once for every user instead of only when the gallery cache is expired.
What is the performance issue with using the cache? If you choose
not to use the cache, that's what the cache configuration parameter in
Ansel is for. Or am I missing something?
New Attachment: Ansel.diff
The patch removes the use of Horde_Cache for galleries but it can be
left, if you think that is better, But static calls should be added
for sure.
Priority ⇒ 1. Low
State ⇒ New
Patch ⇒ No
Milestone ⇒
Summary ⇒ Staticaly images and galleries
Type ⇒ Enhancement
Queue ⇒ Ansel
As the gallery is requestioned multiply times in the page the cache is
called multiply times too. Is better to statically handle galleries.
The patch replaces the cache storage witch classic static calls and
and move the static images container in the the main Ansel_Storage
level so it can be filled by others functions.