On Mon, 2002-05-20 at 05:06, Anthony Baxter wrote:
Bakhtiar A Hamid wrote 5 - squid. throw in squid and stuff will be served much much faster. off course, the pages need to be cacheable i.e with at least Expires field, or better yet put out the necessary cache headers.
This only helps if your pages are mostly static, or mostly the same for each user. Many/most of our pages are highly dynamic, this makes a front end cache a bit exciting. For RAM caching, we use a whole pile of different values as keys - languages, partner, that sort of thing. The sidebar on www.ekit.com is ram cached - right now, the ram cache has 320 different sidebar entries.
Other things I found that helped (digging into the memory here): avoid dtml-tree. It _seems_ neat, but it's a total time sink. work out which SQL methods are getting hit, and when, and cache them.
<dtml-in> is also a thing to avoid if possible - in a test portal front page implementation I rewrote 3 instances of <dtml-in "subfolder.objectValues()"> <tr> <td> <a href="sisu/<dtml-var id>"><dtml-var title_or_id></a> <dtml-if is_admin><dtml-var "muuda_link(id)"></dtml-if> </td> </tr> </dtml-in> with total of ~100 objects into an external method and went from 4.3 pages/sec to 41 pages/sec then I started calling index_html through external method def call_index(self): return self.page_html(None,self) and it went up another 15% to 48 pages/sec I know this speed comes from throwing out some security, but with trusted users it may be worth it. (These numbers are on a 850MHz athlon, Linux, Zope-2.5.1) ------------- Hannu