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. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
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
--On Montag, 20. Mai 2002 11:09 +0200 Hannu Krosing <hannu@tm.ee> wrote:
<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>
Your problem is objectValues *not* dtml-in. The way you do it, all listed objects are actually accessed, which means loaded into memory and such. *Always* use ZCatalogs for listings like the above! 7. Use catalogs whenever possible. It is even reasonable to catalog results from external sources like RDBMS (ZSQLMethods). HTH, Stefan -- BLOWFISH, n. - Preference for beef
On Mon, 2002-05-20 at 12:35, Stefan H. Holek wrote:
--On Montag, 20. Mai 2002 11:09 +0200 Hannu Krosing <hannu@tm.ee> wrote:
<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>
Your problem is objectValues *not* dtml-in. The way you do it, all listed objects are actually accessed, which means loaded into memory and such. *Always* use ZCatalogs for listings like the above!
But I _do_ need them all. How else can I display their id ?
7. Use catalogs whenever possible. It is even reasonable to catalog results from external sources like RDBMS (ZSQLMethods).
Thanks. I'll look at it. ----------- Hannu
On Monday 20 May 2002 11:06 am, Anthony Baxter wrote:
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.
yes - dynamic and personalized pages are a pain. we havent done that yet. however, a 5 minute cache age will save zope a few cpu cycles :) avoid personalizing public pages? ie - dont include "welcome Mr Foo Bar, etc etc"
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.
Anthony
-- http://www.kedai.com.my/ http://www.kedai.com.my/eZine http://www.zope.org/Members/kedai http://www.my-zope.org How can I laugh tomorrow, if i can't even smile today.
participants (4)
-
Anthony Baxter -
Bakhtiar A Hamid -
Hannu Krosing -
Stefan H. Holek