[Grok-dev] Re: KSS lag?

[Balazs Ree]

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