[Grok-dev] Re: KSS lag?

[daniel]

Very nice! Thanks Balazs!
Just by going through apache, with no cache configuration on apache it cut
the original load time from 12 seconds to 6 and the cached load time from
1.5 seconds to 0.5.

Strange results but nevertheless much better and with no mod_cache
configuration.

On Jan 13, 2008 2:14 AM, Balazs Ree <ree at ree.hu> wrote:

> Hi Daniel,
>
> On Sat, 12 Jan 2008 17:48:38 -0500, daniel wrote:
>
> > On Jan 12, 2008 5:08 PM, Godefroid Chapelle <gotcha at bubblenet.be> wrote:
> >
> >> daniel wrote:
> >> > Thanks,
> >> >
> >> > Here are my results on FireFox 3 beta2 with firebug 1.1b10:
> >> >
> >> >
> >> > Console in debug:
> >> > http://img242.imageshack.us/img242/9189/
> firefox3b2firebug11b10djd7.jpg
> >> > <http://img242.imageshack.us/img242/9189/
> firefox3b2firebug11b10djd7.jpg>
> >> >
> >> > Notice the two errors in the console.
> >>
> >> I am surprised, I do not see those errors on my machine.
> >>
> >> Which FF version do you use ?
> >
> >
> > *firefox 3 beta2 for the screenshots with the errors. They don't appear
> > in other versions.*
>
>
> We have not tested with FireFox 3 beta yet. We will certainly check out
> this problem, and make sure to handle it before FireFox 3 goes to stable:
> either by fixing the bug in Zope/kss, or reporting it to FireFox for a
> fix.
>
>
> >> I do not understand what you say here : do you mean that this 12 secs
> >> delay happens at *each* page load even in dev mode ?
> >>
> >> In dev mode, we cache kukit.js in memory in the server : IOW , the
> >> first time kukit.js is requested after server restart, it will be long.
> >> However, the latter request should be very quick.
> >>
> >> Can you give more details ?
> >>
> >>
> > *the 12 second delay happens not because of a server restart, but
> > because I cleared my browser's cache. It only happens once, the first
> > time after a browser cache clear. It occurs whether KSS was in
> > production or devel mode.* *The subsequent page loads only take 1.4
> > seconds unless I clear the browser cache again.*
>
> With kss we follow the exact same resource handling strategy of what Zope
> does (with some small improvements that I would not enter here).
>
> This is the following: Zope does _not_ ever cache the
> resources themselves. If the browser asks for the resource with the If-
> Modified-Since header set, and the resource has not changed since (ie, if
> Zope is not in debug mode, this is always the case between restarts),
> then Zope does _not_ return the resource but simply says "the resource
> has not changed". This instructs the browser "Use what you have!".
> However if the browser does _not_ set the If-Modified-Since header, then
> this tells Zope that it needs to provide the resource unconditionally,
> and the kukit.js is cooked again (slow).
>
> This means if you force to clear all the caches then this is the expected
> behaviour. If Zope is asked to provide the resource, it will provide it,
> and since it is not cached inside Zope, it needs to cook it again.
>
> We also started to implement different caching strategies with the
> kukit.js resource handling, this can be set from the concatresource.zcml
> file in kss.core. Namely: in-memory caching of the cooked resource is
> possible. However this is only to speed up work during development, and
> is _not_ intended to use in production. While it would be possible to
> implement more sophisticated caching strategies (like on-disk caching) of
> the resource from within Zope, there is a much better way to achieve
> this: in production you should _always_ use an upstream cache (Squid,
> apache mod_cache, etc.) which does this job in a much better way then
> what we could implement, and results that the requests for kukit.js will
> not ever reach Zope for a second time.
>
> With this I am not saying that we will not improve the caching story of
> kss, We will make necessary improvements to speed up life of the
> developer. But: in production, I believe that instead of reimplementing
> custom caching solutions inside Zope, we should rely on existing
> solutions (like Squid) specialized for this task.
>
> In addition: obviously we need to start testing with this new browser
> version and most particularly, have a look if it sends the If-Modified-
> Since headers to Zope in the correct way.
>
> Best wishes
>
>
> --
> Balazs Ree
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>



-- 

-- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080113/8725c081/attachment.htm