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