Gallery - Sloooow since update to latest version
Permalink
Since updating both C5 and the Gallery module to the latest versions, it is now very slooooow.
A gallery page with around 40 images used to load in 2-3 seconds, is now taking around 10 seconds.
Anyone else got similar issues?
Any ideas how to fix it?
A gallery page with around 40 images used to load in 2-3 seconds, is now taking around 10 seconds.
Anyone else got similar issues?
Any ideas how to fix it?
which gallery? the one made by C5? the flash 1 which 1?
The Gallery made by C5
there's a flash gallery, and then a regular image gallery, both by us..
is there a URL you can point us to?
is there a URL you can point us to?
These ones:
http://www.jewelleryawards.com.au/2007/gallery/...
http://www.jewelleryawards.com.au/2005/gallery/...
Prior to upgrading, they used to load in 2-3 seconds, now 10+ seconds.
http://www.jewelleryawards.com.au/2007/gallery/...
http://www.jewelleryawards.com.au/2005/gallery/...
Prior to upgrading, they used to load in 2-3 seconds, now 10+ seconds.
Doing some debugging, it shows that the html page took 10 seconds to load, while each of the images loaded in milliseconds, indicating the delay is with the script rather than downloading images etc.
After reverting back to 5.3.2 the issue goes away and the galleries load within 2-3 seconds.
To test this further, I did a clean install of 5.3.3.1 and the latest gallery and uploaded a number of images and immediately experienced the delay again (i.e. a gallery of around 40 images), so it seems there is some sort of conflict or issue with the latest C5 and latest gallery
To test this further, I did a clean install of 5.3.3.1 and the latest gallery and uploaded a number of images and immediately experienced the delay again (i.e. a gallery of around 40 images), so it seems there is some sort of conflict or issue with the latest C5 and latest gallery
What mode are you running your site in ? Development mode or production mode ? I don't know if it still matters but one mode used to do alot more work in the background then the other.
We tried all sorts of combinations, trying to troubleshoot the issue, including both development mode and production mode, cache on and off, cache cleared, etc.
The delay appeared the moment we upgraded to 5.3.3 (and 5.3.3.1) and disappeared the moment we reverted back to 5.3.2.
The delay appeared the moment we upgraded to 5.3.3 (and 5.3.3.1) and disappeared the moment we reverted back to 5.3.2.
5.3.3 and 5.3.3.1 need php 5.2+. 5.3.3.1 made a few fixes that allow you to stay on php < 5.1, but maybe that's an idea. Other then that might be a bug.
we're looking into this.
PHP is 5.2.9
With a small gallery of 5-10 images you don't notice the issue, but on a bigger gallery of around 40-50 images the delay is significant.
This suggests that the delay is directly related to the size of the gallery.
With a small gallery of 5-10 images you don't notice the issue, but on a bigger gallery of around 40-50 images the delay is significant.
This suggests that the delay is directly related to the size of the gallery.
It's worth your while to go download the gallery update. I just posted it. It's 1.5.2. If you want to install it manually, the only changes from 1.5.1 are contained in controller.php. Basically, it's a restructuring to the way the script is written. The gallery, as it stands currently, is resource intensive, and a large gallery will generate a lot of database queries. However, the way the gallery was written, those queries were being run far more often than they needed to be (multiple times on each page.) This should now be eliminated.
Additionally, you'll also encounter some slowness the first time you add a gallery to a page, as the images you're adding will have to have their thumbnails generated. This should only happen on first render, however.
Additionally, you'll also encounter some slowness the first time you add a gallery to a page, as the images you're adding will have to have their thumbnails generated. This should only happen on first render, however.
The main issue appears to be with C5 v5.3.3.x rather than the Gallery.
C5 v5.3.2
All versions of Gallery are fast (approx 2 seconds for 40 images).
C5 v5.3.3.x
Gallery 1.5.1 - approx 10 seconds
Gallery 1.5.2 - approx 6 seconds
So although the new gallery has lead to speed improvements, the underlying issue appears to be with C5 v.5.3.3.x
FYI, caching is on and I have double checked the load times repeatedly
C5 v5.3.2
All versions of Gallery are fast (approx 2 seconds for 40 images).
C5 v5.3.3.x
Gallery 1.5.1 - approx 10 seconds
Gallery 1.5.2 - approx 6 seconds
So although the new gallery has lead to speed improvements, the underlying issue appears to be with C5 v.5.3.3.x
FYI, caching is on and I have double checked the load times repeatedly
Can you check something for me? When you're viewing the gallery, can you open one of the gallery thumbs in a new window? To see it's filename? It should be something like a long string of gibberish (it's an md5 hash.)
Then, reload the page, and take the same thumbnail and open it in a new window? It SHOULD have the same filename, but I'm wondering if your system is setup in such a way that is regenerating the thumbnails on every load. We _did_ make a slight change to the way this works in 5.3.3. and if it's not happy on your system it could lead to regeneration on every page load, for any c5 function that uses the auto-thumbnailer (like the gallery).
Then, reload the page, and take the same thumbnail and open it in a new window? It SHOULD have the same filename, but I'm wondering if your system is setup in such a way that is regenerating the thumbnails on every load. We _did_ make a slight change to the way this works in 5.3.3. and if it's not happy on your system it could lead to regeneration on every page load, for any c5 function that uses the auto-thumbnailer (like the gallery).
If this isn't it - it's also possible that it's just our new approach to attributes. They're much beefier now. In a subsequent release we're going to cache all attribute values for files the same way we do for pages, which will drastically reduce any attribute-related SQL calls.
The image filenames remains the same each time, so it is using the cache and not regenerating them.
I'm guessing it's related to the new approach to attributes.
The speed difference between 5.3.2 and 5.3.3.x is significant - around 3-4 times slower.
With 5.3.2 a gallery of around 40 images loads virtually instantaneously (around 2 seconds) whereas in 5.3.3.x you begin to wonder if you mis-clicked the link or if the server has stopped responding, then around 6 seconds later the page loads.
When it does load, all the images appear quickly, suggesting that the delay is related to the script / db calls not to the load time of the images.
I'm guessing it's related to the new approach to attributes.
The speed difference between 5.3.2 and 5.3.3.x is significant - around 3-4 times slower.
With 5.3.2 a gallery of around 40 images loads virtually instantaneously (around 2 seconds) whereas in 5.3.3.x you begin to wonder if you mis-clicked the link or if the server has stopped responding, then around 6 seconds later the page loads.
When it does load, all the images appear quickly, suggesting that the delay is related to the script / db calls not to the load time of the images.
.. at dashboard->add functionality->update add-ons.
will test manually
will test manually
To save our servers the marketplace response is cached every once in awhile, so if an update doesn't appear you can try clearing your cache to check again.
