For non-cacheable pages that can't be speeded up by a reverse proxy, there
might be two other possibilities worth looking at as well.

If Zbabel is mainly needed for the production/maintenance of translations
rather than for really dynamic pages it might be possible to use ZMirror for
semi-static per language templates generated by ZBabel that get combined
dynamically with the dynamic non-translated bits.

For really dynamic translations, if the database hits are still too much for
some users, despite being read only and therefore usually in buffers, it
might be possible to copy the maintenance ZBabel database stored in a
persistent SQL database from the management screens into a RAM Gadfly
database used by the actual page generation.

-----Original Message-----
Andrew Kenneth Milton
Sent: Friday, July 21, 2000 10:31 AM
Subject: Re: [Zope] ZBabel performance??

+----[ [EMAIL PROTECTED] ]---------------------------------------------
| Hi,
| I was able to install and test the ZBabel product.
| Very nice product indeed!!  I have a question about performance..

Thanks :-)


|  However my concern that if the page is accessed by thousands
| of people, does Zope cache the translated text and serve it? does ZBabel
| do that? or is there a way to do that?

If you are passing query_string parameters into your page you will
not be able to cache the pages anyway.

If a page is cacheable then you can setup a HTTP accellerator in front of
Zope that will cache the rendered pages. I don't know what your current
network topology is like, so it's a little hard to comment.

I can look at adding caching into ZBabel, but, it's not high on my priority
list at the moment... I'm currently pounding the bricks. I'll try to make
time over the weekend to have a look (I may be able to use the Zope
Machinery to do the caching).

| I do not want to hit the database
| everytime someone requests that page.. Our site is usually translated to 5
| languages and we had developed a Perl script that would read php tags and
| create static pages becuase of that problem, and in this case we do not
| know at all what happend in eth backend..

Out of interest how many hits per hour are you doing?

I worked on a largish portal system (ASP *puke*) and they had no problem
going to the DB very very frequently. The key for the phrase is 32 bytes,
it should be very quick to look up, even in a poorly tuned MySQL.

Totally Holistic Enterprises Internet|  P:+61 7 3870 0066   | Andrew Milton
The Internet (Aust) Pty Ltd          |  F:+61 7 3870 4477   |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068    |[EMAIL PROTECTED]|

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to