Loading...
 
Skip to main content

Features / Usability


Slow Image Galleries?

posts: 1

I just installed TikiWiki 1.8.1 and have set it up on a test community site. Everything looks good and I've been happy with everything so far except that the images and thumbnails in the image galleries take FOREVER to load. I have the image galleries set to save to disk and it seems to be properly storing the image and the thumbnail in the directory i specified, but loading the gallery index can take up to a minute and loading images takes upwards of 20 seconds for a fairly small image (40k).

Not sure if this is a common problem or there is another setting I should check to speed things up? When i click the files themselves outside the gallery (i.e. loading up the directory where its saving the actual image and thumbnail files in a browser) they load up quickly, but trying to view them in the gallery takes forever.

I didnt see much in the forums about this problem so I figured I'd check to see what might cause the problem. Any suggestions would be greatly appreciated. Thanks!



posts: 63 United Kingdom

me too ๐Ÿ˜‰
Fix did speed up thumbnails loading although I remember 1.7 lolading them faster ๐Ÿ˜›


posts: 1001 Canada
Hi tarka and Russ, thanks for commenting this but it would be better if you and others could comment on the bug tracker directly. At this state this is still relevant information.

posts: 2881 United Kingdom

I think a lot here is down to Server and Browser compatibility.

I use Tiki now 1.8 for managing my large collection of Digital Photos close on 7000, and not really noticed any problems here.

Server: Apache 2 on Fedora Core
Client: Mozilla 1.6 on Fedora Core (diff computer tho)

Damian


posts: 21 Netherlands

In 1.8.2 the problem still occurs.
A fix suggested at SF bug page helped.

my conf: Apache 2.0.49, php 4.3.4, RedHat9, FireFox 0.8


posts: 21 Netherlands

Gotcha!

I think I just identified a problem.
As in my other post, it is related to gzip compression.

When we explicitly set Content-length header, we always give it a value of a source file. When compression is on, the content becomes smaller, hence browser probably waits for more data (which never arrives).

Switching compression off helps just as well as removing related header from show_image.php


posts: 63 United Kingdom

So then solution is to make the header function only called when compression is off? Or are we not able to test if compression is being used without tiki's say-so (outside the "use gzip compression" checkbox)?

Should be easy right?


posts: 21 Netherlands

In fact, I would remove all 'Content-Length' headers from tiki-created pages.
Reason is, the output can be compressed by php itself depending on various settings in php.ini.
And I'm not sure if the zlib or gzip compression correctly modifies headers when it compresses data.
Some PHP and HTTP expert could say probably more ๐Ÿ˜Š


posts: 22 Switzerland

thx!

my image gallery is much more fast now ...

... Then I looked at

show_image.php. It didn't change much. But I found this
line added by mose (revision 1.12) :
header ("Content-length: ".$imagegallib->filesize);
I didn't check filesize() yet, but I would be 95% sure

that removing this line fixes (or improves the result) ...


this does the job!
i am using twiki 1.8RC3

kiilo