Re: Use of 304 - not modified

Guido Wesdorp wrote:

> I think investigating possible uses of 304 Not modified would definitely 
> make sense, although I have the feeling it might actually turn out to 
> not be much of a win. To find out when objects were last modified, you 
> will have to 'wake up' all of the objects (retrieve them from the ZODB) 
> you want to know the modification date for, which is usually one of the 
> most expensive parts of a request. I'm not all that sure whether just 
> processing the content on each request will make much of a difference in 
> CPU time (although I think it will make a difference in network traffic, 
> but I don't think that's the most interesting point to optimize, usually 
> the network isn't Zope's bottleneck).

Measurements showed a quite large dependence of what people do when
casting Silva output into their own layout. A plain example Silva page
as delivered renders 7-10 times faster than a common page in ETH
layout, fully featured with all kind of gadgets.

There is a real drop in performance if a ZEO client does not find an
object in the Zope object cache, that's right, but then you're lost
anyway. And if Zope has to load objects for validation chances are that
this validation will fail, so we have to access the objects anyway for
rendering the page. After a failed validation, we have at least
preloaded all objects.

I made some tests (1000 loop steps each):

1. date lookups
2. page rendering
3. tree collection (one level in a production site root)

If using the default Infrae layout (in msecs):

1. 350, 2. 22'000, 3. 20'000

If using the default ETH layout home page, containing no extra box
feeder documents or code elements (left side subnavigation turned off):

1. 350, 2. 270'000, 3. 20'000

Page rendering may be up to 15 times slower than a tree lookup, so if a
validation collects a tree and finally the check fails, we would add
only 10% of processing time. And this is only the default layout, some
customer sites I measured last another 5 times longer to render.

Of course we have to pay for this, at least by keeping more objects in
RAM, because they will be called more often as with static caching. But
the age of 64 bit memory space has come...

Regards

Bengt


The test code:

------------

loops = 1000
# the test loop
i = loops
start = DateTime().millis()
while i > 0:
  context.index.get_modification_datetime()
  # The other methods tested, in duplicated loop blocks:
  # 2. getattr(context, 'content.html')(view_method='view')
  # 3. context.silva_ethz.ETH.baug.baug.baug.get_public_tree(1)
  i -= 1
end = DateTime().millis()
print end-start