[Seaside] slow picture loading
Bob Arning
arning315 at comcast.net
Mon Nov 26 03:12:58 UTC 2012
I took a look at your site and it reminded me of a problem I had once -
not really the same symptoms, but there may be some commonality as to
cause. What I was seeing in my app was that occasionally one or two
images might not load in the browser. No real pattern as to which
images, but it did seem to happen more when the browser sent multiple
requests to the server in a very short period of time. What I did was
insert a delay in responding to a file request if it was too soon after
the previous request. I'm wondering if something similar is happening to
you, only that the long file times correspond to a response that did not
get sent/received initially, but did after a timeout/retry. What you
might do is try to capture in the server when you receive requests and
when you think you are sending the response. Maybe the long file times
will show a second request or somesuch. I've attached the code I
modified below to aid in experimentation.
Cheers,
Bob
documentForFile: arg
| wait result waitList myFirstTime |
self prepare.
myFirstTime _ Time millisecondClockValue.
lastRequestTime ifNil: [lastRequestTime _ 0].
lastRequestTime _ lastRequestTime min: myFirstTime.
waitList _ #().
[
wait _ 20 - (Time millisecondClockValue - lastRequestTime) min: 20.
wait > 0
] whileTrue: [
waitList _ waitList,{wait}.
wait asString,' wait for ',arg asString,' ' displayAt: 0 at 20.
(Delay forMilliseconds: wait) wait.
].
lastRequestTime _ Time millisecondClockValue.
result _ self documentForFileInner: arg.
TallyingDocumentTimes ifNotNil: [
TallyingDocumentTimes add: {
myFirstTime.
Time millisecondClockValue.
result size.
waitList.
arg.
"thisContext longStack."
}.
].
^result
On 11/25/12 6: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20121125/3213a080/attachment.htm
More information about the seaside
mailing list