Mailing List Archive

A technique that's worked for us in the past is to use lwp-request or
similar to cache the content of the static/almost static portions of the
site into files with a .cache extension (e.g., "/foo/script1.cache")...when
a request is made to /foo/script1.epl, before we pass the request to
HTML::Embperl, we use a TransHandler to check if a .cache file exists with
the same name (and meets some other criteria).

If the .cache file exists, we simply serve it and the request stops there.
We saw the hits to our database decrease by almost 1/3, but your mileage
will vary based on your particular setup. The extra stats/etc. required to
find the .cache file on the filesystem increase the time (minimally) to
process each .epl page, but the reduced load on our database was worth the
extra load.

-Alex

-----Original Message-----
From: stenseto@ns1.davanitadesign.com
[mailto:stenseto@ns1.davanitadesign.com]On Behalf Of Owen Stenseth
Sent: Wednesday, March 22, 2000 2:01 PM
To: embperl@perl.apache.org
Subject: Database driven site growing pains (Execute result caching).


Fellow Embperl Users,

I have a situation that I would like to share with everyone here to
determine if there are other people in the situation and if anyone can
shed any light on it.

First some background, I have been working with Embperl for about 6
months now. It's speed and flexability have impressed me as well as it's
stability. Our site (www.pdamd.com) is a database driven site that uses
Embperl to generate dynamic pages from the database. This is a common
use of Embperl from what I can gather from the list over the last few
months.

As with some other people I am sure there are certain parts of the site
that are very dynamic and other smaller components that do not change as
often. Storing information in a database greatly simplifies the content
management of the site but presents a problem when every request hits
the database for information.

Two solutions that I can think of to the problem are

1. generating static versions of certain components
2. caching Execute output with certain expire conditions

My thoughs on the Execute output caching would be to allow a component
to cache a result based upon the component itself and any parameters
that when passed to the component endup generating a different result.
This could be used to cache a side panel that is used for (in our case)
a palm only version of our site.

I am wondering if anyone else is having similar experiences/growing
pains and would like to hear (read) there thoughts.

--
Owen Stenseth
Lead Web/PDA Developer
PDA Verticals Corp.

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org

>
> As with some other people I am sure there are certain parts of the site
> that are very dynamic and other smaller components that do not change as
> often. Storing information in a database greatly simplifies the content
> management of the site but presents a problem when every request hits
> the database for information.
>
> Two solutions that I can think of to the problem are
>
> 1. generating static versions of certain components
> 2. caching Execute output with certain expire conditions
>
> My thoughs on the Execute output caching would be to allow a component
> to cache a result based upon the component itself and any parameters
> that when passed to the component endup generating a different result.

Output caching will be supported in the next Embperl version, which
(hopefully) appears during april

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------