Is a Gallery of SLIR-loaded-images possible?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a page with over 40-50 images loaded using SLIR.

What is the expected output? What do you see instead?
It loads the image one by one VERY VERY slowly.

What version of the product are you using? On what operating system?
revision 129, server: shared linux, client: windows xp/vista/7

Please provide any additional information below.
If you create a gallery of around 40-50 or more images all loaded at the same 
time using SLIR, it seems that the loading time of the page is 10 times the 
usual. Images load one by one and takes around 10 seconds each to load.

All images, once SLIR'ed are 100px X 100px and weight 3 to 7kb. Source is 
around 400 X 400 and weight 16 to 20kb. If I'd put all 50 images in thumbnail 
version of this same dimensions and weight, the loading time is much much 
quicker (without using SLIR).

Once they are all loaded, the second loading is WAY faster, but it looks like 
it is my CLIENT cache, and not the server SLIR's cache. Because if I set my 
browser cache to OFF, the huge loading time comes back, even if my 
"cache/rendered" folder is fully filled on the server (so server-cache IS 
working).

I have no "ready-to-show" SLIR image gallery, but I'm sure you can reproduce 
this easily.

Finally, maybe SLIR is not intended to be use as "MASS" resizing for something 
like a Gallery image ? Or is it ?

Thanks for you help, very much appreciated.
-Joel

Original issue reported on code.google.com by flamesjo...@gmail.com on 24 Feb 2011 at 10:30

[GoogleCodeExporter]

SLIR should be able to handle a page that has a lot of images on it. If it 
isn't there could be something wrong.

As a trial, I created a page that had 22 random images on it that were all 
resized and cropped to 50x50 pixels. I made the same exact page but linked up 
the cropped 50x50 pixel images directly (not through SLIR).

Testing with Firebug, hard reloading (to bypass the browser cache) 10 times, 
these are the page load times I came up with:

Page with SLIR:

178ms (onload: 207ms)
65ms (onload: 182ms)
213ms (onload: 235ms)
211ms (onload: 230ms)
221ms (onload: 240ms)
250ms (onload: 273ms)
232ms (onload: 250ms)
215ms (onload: 232ms)
233ms (onload: 256ms)
238ms (onload: 251ms)
251ms (onload: 268ms)

Page without SLIR: 

206ms (onload: 220ms)
293ms (onload: 291ms)
269ms (onload: 265ms)
134ms (onload: 269ms)
260ms (onload: 259ms)
243ms (onload: 245ms)
274ms (onload: 273ms)
238ms (onload: 235ms)
261ms (onload: 253ms)
228ms (onload: 235ms)

However, the images should load concurrently, not one at a time. Can you give 
me a link where I can see this happening?

Original comment by joe.lencioni on 25 Feb 2011 at 7:13

[GoogleCodeExporter]

Hi Mr Lencioni,

Thanks for your quick answer, it is very much appreciated!

Here's a link for the website we are currently working on: http://bit.ly/eZVpqL

The html markup is not very optimal, we know, but we cant afford to redo all 
the html again. So here's how it works:

There's 4 column in the center. Each "block" is made of a DIV containing a SLIR 
background image. Within each div is an A tag, also containing a SLIR 
background image. When you roll over the first DIV, it is hidden and the A 
background is showed, so it looks like a "rollover" effect.

There is a total of 50 images loaded with SLIR.

We used SLIR in previous projects and it worked perfectly every time, only this 
is the first time we have over 25 images loaded with SLIR at the same time.

NOTE: There is an FLV video loading on the page. I tough at first that was 
causing the loading issue, but it's not. Removing the video, or taking only the 
images apart of this page on a blank page results in the same loading time when 
using SLIR.

If you would need a blank page with only the images, I can also do that if it 
helps testing.

THANKS a ton for helping us!!!
-Joel

Original comment by flamesjo...@gmail.com on 25 Feb 2011 at 7:33

[GoogleCodeExporter]

Wow, that is awfully slow.

According to the headers sent with the images, they are coming out of SLIR's 
request cache, which is currently the optimal way for SLIR to serve the files. 
This leads me to believe that SLIR is working as it should be.

Are you running an opcode cache on your server, like APC? If not, I would 
highly recommend enabling APC--it will probably make your whole website a lot 
faster.

Original comment by joe.lencioni on 25 Feb 2011 at 8:03

[GoogleCodeExporter]

Hi again Mr Lencioni,

We are not running any cache optimization code on the server at the moment. 
This is hosted on a sharing account, so we dont have taht much of control over 
the web server.

But if I turn off loading images with SLIR and integrate the images in "static" 
mode, the loading time is very quick. So it kind of narrow the issue down to 
the SLIR script.

If you create an empty page with 50 images loaded by SLIR, do you have the same 
issue? If no, maybe your APC is really making that much of difference? So SLIR 
images gallery of ~40 images or more would not be possible on shared hostings?

Thanks for your help!
Keep us posted if you find anything on that issue
-Joel

Original comment by flamesjo...@gmail.com on 25 Feb 2011 at 8:52

[GoogleCodeExporter]

No, I don't have any issues with pages that have 50 images loaded by SLIR.

However, it occurs to me that there may be something else going on here. Is 
your server configured to auto_prepend or auto_append any code? If so, there 
may be another script that is slowing things down.

It would be helpful if you could profile SLIR using something like Xdebug to 
determine exactly what is happening.

Original comment by joe.lencioni on 25 Feb 2011 at 9:08

[GoogleCodeExporter]

Hello again Mr Lencioni,

I'm not sure about the prepend/append configuration of my server, is there any 
way to check this using the Cpanel?

I made a simple version of the SLIR gallery, here it is: http://bit.ly/fKZzI7

This page loads only SLIR and the styles of the pages. -ALL- other scripts has 
been removed to make sure nothing else is slowing down the loading.

NOTE: You will have to empty or turn OFF your cache to view this page 
correctly. At first sight, my co-worker loaded it instantly cause his browser 
had already all images in cache. Once reloaded with CTRL-F5 (in firefox) the 
super tremendous loading comes back.

Thanks again for your precious help!
-Joel

Original comment by flamesjo...@gmail.com on 25 Feb 2011 at 9:55

[GoogleCodeExporter]

I'm not familiar with cpanel, so I can't help you out there. Do you have access 
to a code profiler?

Also, can you try changing a few parts of slir.class.php as specified here:

Change the serveFile() function to this:

private function serveFile($imagePath, $data, $lastModified, $length, 
$mimeType, $SLIRHeader)
{
    if ($imagePath !== NULL)
    {
        if ($lastModified === NULL)
        {
            $lastModified   = filemtime($imagePath);
        }
        if ($length === NULL)
        {
            $length         = filesize($imagePath);
        }
        if ($mimeType === NULL)
        {
            $mimeType       = $this->mimeType($imagePath);
        }
    }
    else if ($length === NULL)
    {
        $length     = strlen($data);
    } // if

    // Serve the headers
    $this->serveHeaders(
        $this->lastModified($lastModified),
        $mimeType,
        $length,
        $SLIRHeader
    );

    if ($data === NULL)
    {
        readfile($imagePath);
    }
    else
    {
        echo $data;
    }
}

And serveCachedImage() function to this:

private function serveCachedImage($cacheFilePath, $cacheType)
{
    // Serve the image
    $this->serveFile(
        $cacheFilePath,
        NULL,
        NULL,
        NULL,
        NULL,
        "$cacheType cache"
    );

    // If we are serving from the rendered cache, create a symlink in the
    // request cache to the rendered file
    if ($cacheType != 'request')
    {
        $this->cacheRequest(file_get_contents($cacheFilePath), FALSE);
    }

    exit();
}

Original comment by joe.lencioni on 25 Feb 2011 at 10:34

[GoogleCodeExporter]

Hello again,

I've changed the functions with the code provided above. I did not notice any 
changes in the loading time tho. If you want to check, the url is the same: 
http://bit.ly/fKZzI7

Thanks for your help!
-Joel

Original comment by flamesjo...@gmail.com on 28 Feb 2011 at 2:29

[GoogleCodeExporter]

Looking at this closer, it seems that the images are being downloaded somewhat 
concurrently, but just not very quickly. Check out the charts here:

http://www.webpagetest.org/result/110228_WY_2MRB/
http://www.webpagetest.org/result/110228_WY_2MRB/1/details/

You have some 404 file not founds on there, resolving them might help a little.

I am considering implementing a mechanism that will allow SLIR to serve some 
requests directly from the cache without invoking PHP--this should 
theoretically make things faster for you.

However, I'm thinking the there are some things that you can do that should be 
able to make a difference:

1. Parallelize static content requests across multiple cookieless hostnames. 
You can use subdomains for this. 
http://code.google.com/speed/page-speed/docs/rtt.html#ParallelizeDownloads

2. Increase the amount of time content can be cached by the browser. 
http://code.google.com/speed/page-speed/docs/caching.html#LeverageBrowserCaching

For SLIR, you can set the $browserCacheTTL variable in your 
slirconfig.class.php file. For example, this will allow SLIR images to be 
cached for up to one year:

    public static $browserCacheTTL  = 31536000; // 365 * 24 * 60 * 60

3. Set up an opcode cache like APC. This should have a very noticeable effect.

Who is your host?

Original comment by joe.lencioni on 28 Feb 2011 at 3:02

[GoogleCodeExporter]

We are from Canada - Quebec - Montreal, so we have a web hosting service that 
you are probably not familiar with, it's a host located in Montreal. Since most 
of our targetted clients are from montreal, this is ideally the best choice in 
web hosting since all their servers are phisically located here. The host is 
iWeb Technology at iweb.ca

Thanks for you suggestions, we will look into it very soon!
-Joel

Original comment by flamesjo...@gmail.com on 28 Feb 2011 at 3:21