[Seaside] slow picture loading

Tue Nov 27 21:06:44 UTC 2012

pier.js has these response headers:

HTTP/1.1 200 OK
Date: Tue, 27 Nov 2012 21:00:21 GMT
Server: Zinc HTTP Components 1.0
Expires: Tue, 27 Nov 2012 21:30:21 GMT
Content-Length: 537
Cache-Control: max-age=1800
Content-Type: application/x-javascript
Via: 1.1 www.humane-assessment.com
Keep-Alive: timeout=1, max=99
Connection: Keep-Alive

so, Zinc would mean Seaside had a hand in it.

Also. looks like you lowered the keep-alive timeout and I'm not seeing 
the 15 second files - the biggest thing I see now is getting jQuery 
downloaded. Progress!

Cheers,
Bob

On 11/27/12 3:54 PM, Tudor Girba wrote:
> Hi,
>
> As far as I see, the javascript files are being served directly through apache. Why do you say differently?
>
> Cheers,
> Doru
>
>
> On 27 Nov 2012, at 21:24, Gerhard Obermann <obi068 at gmail.com> wrote:
>
>> Hi!
>>
>> Why are the js files not served through apache.
>> I have also sometimes long waiting times for the js files only.
>>
>> BTW we are using Nginx. We moved from apache to lighttp to nginx.
>> We also compress all js files into one file before serving.
>>
>> So it seems not be related to the png files only.
>>
>>
>> Cheers
>> Gerhard
>>
>>
>>
>> On Tue, Nov 27, 2012 at 8:34 PM, Tudor Girba <tudor at tudorgirba.com> wrote:
>> Hi Bob and James,
>>
>> Thanks again.
>>
>> It seems to be that the 15s is too much of a coincidence :).
>>
>> I put together two experiments that show that the loading problem depends on the amount of images:
>>
>> - a page with 3 extra images on top of the template. This seems to exhibit the problem for exactly one slow loading image:
>> http://www.humane-assessment.com/test3ExtraImages
>>
>> - a page with only 1 extra image on top of the template. This loads fine:
>> http://www.humane-assessment.com/testOneExtraImage
>>
>>
>> But, I still do not quite understand where to look next. Any further advice?
>>
>> Cheers,
>> Doru
>>
>>
>> On 26 Nov 2012, at 20:41, Bob Arning <arning315 at comcast.net> wrote:
>>
>>> I wrote a Squeak simulation of the browser loading 14 of the files on your page. I used a separate process for each httpGet: and typically were complete in under 1.5 seconds. When I hit reload on the browser, there are often 1 or 2 files taking a bit over 15 seconds. Suggests something different about how the browser requests data vs. my simple simulation.
>>>
>>> Interesting that the response headers are:
>>>
>>> HTTP/1.1 304 Not Modified
>>> Date: Mon, 26 Nov 2012 19:19:23 GMT
>>> Server: Apache/2.2.8 (Ubuntu)
>>> Connection: Keep-Alive
>>> Keep-Alive: timeout=15, max=100
>>> ETag: "392802a-7974-4cf387f145600"
>>>
>>> Is it just a coincidence that the keep-alive timeout is 15 seconds and that the slow files take 15.7 seconds? Attached is an HAR file with the browser timing details.
>>>
>>> Cheers,
>>> Bob
>>>
>>> On 11/26/12 4:27 AM, Tudor Girba wrote:
>>>> Hi Paul, hi James,
>>>>
>>>> Thanks for the answers.
>>>>
>>>> I also thought it has to do with the Apache config, but I had no idea what to look for. Your suggestion certainly look interesting to look into, but I have close to no clue of how to do it. Do you happen to have a bit more hands-on pointers for         how to:
>>>> - increase the resources count
>>>> - add expire headers for the images
>>>>
>>>> ?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On Mon, Nov 26, 2012 at 5:28 AM, Paul DeBruicker <pdebruic at gmail.com> wrote:
>>>> I suspect James has the answer but you might also consider doing the
>>>> following:
>>>>
>>>> -Add expires headers for the images in Apache and people will only have
>>>> to download them once.
>>>>
>>>> -Apache 2.2.8 was released Jan 19, 2008 so I'd definitely spend time
>>>> upgrading to the latest stable version just to get the security
>>>> vulnerability fixes.
>>>>
>>>>
>>>>
>>>> On 11/25/2012 08:11 PM, James Foster wrote:
>>>>> Hi Doru,
>>>>>
>>>>> How many resources do you have loading from the same site? Once I had a problem in which Apache was configured (by default) to only provide ten (10) items per second to the same client. I believe this was an attempt to avoid a denial-of-service attack. When I changed Apache to allow 30 items per second then my site loaded much faster.
>>>>>
>>>>> James
>>>>>
>>>>> On Nov 25, 2012, at 3:24 PM, Tudor Girba wrote:
>>>>>
>>>>>> Thanks. But, somehow, I think size is not really the issue.
>>>>>>
>>>>>> Somehow randomly, one or two of the pictures take significantly more (the delta is measured in seconds) to load than the others.
>>>>>>
>>>>>> And yes, I am using the timeline debugging functionality from the browser.
>>>>>>
>>>>>> It's strange.
>>>>>>
>>>>>> Doru
>>>>>>
>>>>>> On 24 Nov 2012, at 10:26, Gerhard Obermann <obi068 at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Doru,
>>>>>>>
>>>>>>> I would reduce the image size to the displayed size and reduce the bit depth of the png to 8.
>>>>>>> I tried it with home-icons-400-200-37.png.
>>>>>>> Before: 31.092 Bytes
>>>>>>> After: 7.678 Bytes
>>>>>>>
>>>>>>> Cheers
>>>>>>> Gerhard
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Nov 24, 2012 at 8:29 AM, Tudor Girba <tudor at tudorgirba.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am working on a pier page, and I have a couple of images in it that seem to be slow to load, although they are served through apache.
>>>>>>>
>>>>>>> It is true that the images are slightly large (~230K), but still I think they appear too slow.
>>>>>>>
>>>>>>> The example is here:
>>>>>>> http://www.humane-assessment.com/
>>>>>>>
>>>>>>> Anyone has any idea of why this would happen?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "Live like you mean it."
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seaside mailing list
>>>>>>> seaside at lists.squeakfoundation.org
>>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seaside mailing list
>>>>>>> seaside at lists.squeakfoundation.org
>>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "We can create beautiful models in a vacuum.
>>>>>> But, to get them effective we have to deal with the inconvenience of reality."
>>>>>>
>>>>>> _______________________________________________
>>>>>> seaside mailing list
>>>>>> seaside at lists.squeakfoundation.org
>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>>
>>>>> _______________________________________________
>>>>> seaside mailing list
>>>>> seaside at lists.squeakfoundation.org
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>>
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>> <www.humane-assessmen>_______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> --
>> www.tudorgirba.com
>>
>> "Problem solving should be focused on describing
>> the problem in a way that makes the solution obvious."
>>
>>
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> --
> www.tudorgirba.com
>
> "Beauty is where we see it."
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20121127/70aba674/attachment-0001.htm