RE: dynamic vs. mostly static data
Is a package global var, such as %CACHE in the code below, persistent during
the life of a child process? Does each child get a copy of %CACHE after the
parent forks?
Thanks,
Jason
i often do something like this where i allow each individual child
process to cache it's data. i do something like this:
package Apache::Foo;
use strict;
use Apache::Constants;
use POSIX 'strftime';
use constant CACHE_EXPIRES = 3600; # one hour
use vars qw[ %CACHE ];
%CACHE = ();
sub handler {
my $r = shift;
eval {
my $expires = $CACHE{'expires'} || 0;
if ($expires time) {
my @data = some routine ;
my $t = HTML::Template-new(filename = 'foo.tmpl',
die_on_bad_params = 0,
cache = 1);
$t-param('data', \@data);
$CACHE{'data'}= $t-output;
$CACHE{'expires'} = time + CACHE_EXPIRES;
}
$r-print($CACHE{'data'});
};
return print_err($r, $@) if $@;
return OK;
}
1;
btw, i'd really recommend you look into using Template Toolkit. it's a
much more powerful and flexible templating system than HTML::Template,
but i digress (and might start a flame war against myself by saying this).
hth,
ky
Re: dynamic vs. mostly static data
On Fri, Nov 10, 2000 at 10:46:03AM -0800, Jason Liu wrote: Is a package global var, such as %CACHE in the code below, persistent during the life of a child process? Yup. Does each child get a copy of %CACHE after the parent forks? For all intents and purposes, yes. Most OSs will mark those pages Copy on Write. - Barrie
Re: dynamic vs. mostly static data
Perrin Harkins [EMAIL PROTECTED] writes: On Wed, 8 Nov 2000, Marinos J. Yannikos wrote: Only if you don't already have a proxy front-end. Most large sites will need one anyway. After playing around for a while with mod_proxy on a second server, I'm not so convinced; we have been doing quite well without such a setup for some time now, despite up to 70-80 httpd processes (with mod_perl) during busy hours. If you can meet your performance needs without using a proxy front-end, then by all means avoid the extra work. If you find yourself bumping against MaxClients and can't easily fix the problem with more RAM, I recommend you give the proxy approach another look. Personally, I avoided it until the hardware costs of scaling without it became prohibitive. The killer at my last place was having loads of people a long, long way away hanging on to fat apache processes while loading gifs, jpegs and 20k of text. Still, that was before Stas had really got to the root of the memory sharability thing - I'm happy now that we're looking at a couple of meg unshared per process not tens. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - --JAF13974.973674502/hodgkinson.org-- --- End of forwarded message ---
Re: dynamic vs. mostly static data
"PH" == Perrin Harkins [EMAIL PROTECTED] writes: PH against MaxClients and can't easily fix the problem with more RAM, I PH recommend you give the proxy approach another look. Personally, I avoided PH it until the hardware costs of scaling without it became prohibitive. Also, moving all static content, mostly images, off to another server helps tremendously. You ultimately want to end up only doing mod_perl requests on the mod_perl server and leave static content to other processes. It doesn't have to be a proxy front end doing it. See the tuning docs for details. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: dynamic vs. mostly static data
Also, moving all static content, mostly images, off to another server helps tremendously. True, we had an extra thttpd for static content at one point while we were short on memory. Something else that seems to work well, although I can't really explain it, is to disable keepalive support. For some reason, the number of concurrent processes (for a single server setup) went from 70-80 to approx. 20(!), without a noticeable drop in performance or page impressions. My guess is that with such a configuration, since some httpd's are busy generating dynamic pages, those that are available for static content are usually (i.e. with a higher probability) those that just served static content and finished quickly, so the number of httpd's stays near the number of concurrent dynamic page accesses + max. number of concurrent connections. With keepalives on, httpd's need much more time for one page impression if the connection is slow, so that should explain why there are so many of them. Does this make sense? Regards, -mjy -- Marinos J. Yannikos Preisvergleich Internet Services AG, Linke Wienzeile 4/2/5, A-1060 Wien Tel/Fax: (+431) 5811609-52/-55
Re: dynamic vs. mostly static data
On Wed, 8 Nov 2000, Marinos J. Yannikos wrote: Something else that seems to work well, although I can't really explain it, is to disable keepalive support. For some reason, the number of concurrent processes (for a single server setup) went from 70-80 to approx. 20(!), without a noticeable drop in performance or page impressions. KeepAlive will cause a connection to stay open (and a process to stay busy listening on it) for a period of time after the response is sent, even if nothing at all is happening on that connection. I think the default wait is 15 seconds. That can really add up fast when you have your MaxClients set at less than 100. KeepAlive is great on a proxy server or dedicated image server though. - Perrin
Re: dynamic vs. mostly static data
If you have a caching proxy server running in front of your mod_perl server (like mod_proxy or Squid), you can just set Expires headers in your pages and this will be handled for you by the proxy. True, both methods have advantages and disadvantages. The advantages of using mod_rewrite and static pages are: - less configuration / maintainance overhead - somewhat fewer resources needed - no extra care needed with headers - static pages can be removed at any time and kept around as long as needed, individual static pages can be removed and regenerated The obvious disadvantage is that it may be tricky to find / maintain an URL/file encoding scheme that can handle all the possible arguments for dynamic pages. -mjy -- Marinos J. Yannikos Preisvergleich Internet Services AG, Linke Wienzeile 4/2/5, A-1060 Wien Tel/Fax: (+431) 5811609-52/-55
Re: dynamic vs. mostly static data
On Tue, 7 Nov 2000, Marinos J. Yannikos wrote: If you have a caching proxy server running in front of your mod_perl server (like mod_proxy or Squid), you can just set Expires headers in your pages and this will be handled for you by the proxy. True, both methods have advantages and disadvantages. The advantages of using mod_rewrite and static pages are: - less configuration / maintainance overhead Only if you don't already have a proxy front-end. Most large sites will need one anyway. - no extra care needed with headers You don't have to add Expires headers, but you do have to add a section to each script that captures the output and puts it in a static file. - static pages can be removed at any time and kept around as long as needed, individual static pages can be removed and regenerated We took the URL-filename hashing from mod_proxy and used it to make a little program that can delete a URL from the cache on command. This is not a standard part of the distribution though. The obvious disadvantage is that it may be tricky to find / maintain an URL/file encoding scheme that can handle all the possible arguments for dynamic pages. If you're doing this on a mod_perl server already, it might actually be easier to write a TransHandler for it, and use an MD5 hash or something to generate the file names. Matt Sargent does this sort of thing in AxKit, so that might be a place to steal code from. - Perrin
Re: dynamic vs. mostly static data
Only if you don't already have a proxy front-end. Most large sites will need one anyway. After playing around for a while with mod_proxy on a second server, I'm not so convinced; we have been doing quite well without such a setup for some time now, despite up to 70-80 httpd processes (with mod_perl) during busy hours. Since we try to keep our website very responsive, the additional latency we observed with a mod_proxy based front-end was noticeable (still in the tenths of a second range though). Perhaps with some more tweaking we could have avoided that (yes, we did turn off Keepalive for the mod_perl back-end!) , but together with the other drawbacks (remote IP tracking is difficult / impossible in some cases, lots of IfModule mod_proxy.c sections in the config files etc.), it seemed to be too much of a hassle to use while we still have enough memory for all the httpd processes. Regards, -mjy -- Marinos J. Yannikos Preisvergleich Internet Services AG, Linke Wienzeile 4/2/5, A-1060 Wien Tel/Fax: (+431) 5811609-52/-55
Re: dynamic vs. mostly static data
On Wed, 8 Nov 2000, Marinos J. Yannikos wrote: Only if you don't already have a proxy front-end. Most large sites will need one anyway. After playing around for a while with mod_proxy on a second server, I'm not so convinced; we have been doing quite well without such a setup for some time now, despite up to 70-80 httpd processes (with mod_perl) during busy hours. If you can meet your performance needs without using a proxy front-end, then by all means avoid the extra work. If you find yourself bumping against MaxClients and can't easily fix the problem with more RAM, I recommend you give the proxy approach another look. Personally, I avoided it until the hardware costs of scaling without it became prohibitive. - Perrin
Re: dynamic vs. mostly static data
On Nov 3, 9:52am, Ken Y. Clark wrote:
btw, i'd really recommend you look into using Template Toolkit.
Indeed. One of the nice things about TT (in the author's humble opinion)
is that you can use the same presentation templates to render static HTML
as for dynamic HTML.
For example, you can create a template which uses the DBI plugin to
access some data and display it nicely (see the other thread on "a web
interface to visualize tables").
e.g.
[% INCLUDE header
title = "Some Funky Data" %]
[% USE DBI(dsn) %]
[% USE Table(DBI.query('SELECT * FROM blah'), rows=10) %]
table
[% FOREACH row = Table.rows %]
tr
[% FOREACH item = row %]
td[% item %]/td
[% END %]
/tr
[% END %]
/table
[% INCLUDE footer %]
You can deliver this page from Apache/mod_perl to have it constructed
on-the-fly, or you can use 'tpage' or 'ttree' (distributed with the
Template Toolkit) to create the content offline as a static page.
Both dynamic and static pages can shared the same presentation elements
(e.g. header/footer in this example), and both have full access to the
TT plugins to fetch DBI data, display tables, etc.
'ttree' is your friend. You can define as many templates like this as
you like, stuff them all in a directory somewhere, setup a ttree config
file, and then just call 'ttree -f my_config_file' to have it process
all and any such templates and copy the output to your static HTML
directory.
See the copious TT documentation (perldoc ttree, perldoc Template) for
further info. The TT web site also has my paper from TPC4 which
discusses these techniques at greater length.
http://www.template-toolkit.org/
HTH
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: dynamic vs. mostly static data
"AW" == Andy Wardley [EMAIL PROTECTED] writes: AW On Nov 3, 9:52am, Ken Y. Clark wrote: btw, i'd really recommend you look into using Template Toolkit. AW Indeed. One of the nice things about TT (in the author's humble opinion) AW is that you can use the same presentation templates to render static HTML AW as for dynamic HTML. I've been trying to wrap my head around TT the last few days. What I would like to do is make each document just plain HTML content, and have one template that my server applies to the docs. That is, the template would be something like head titleMy Site/title /head body tr td[% stick in body of article here "document.main" %]/td td[% stick in related info here "document.sidebar" if it exists %]/td /tr /body That is, I have exactly one template that I apply to each document. Right now I do that using Sandwich and some pre-processing, but I'd much rather let a real template system do it so I can put parts in various places. Is TT the something that will let me do this without too much headache?
Re: dynamic vs. mostly static data
On Mon, 6 Nov 2000, Vivek Khera wrote: head titleMy Site/title /head body tr td[% stick in body of article here "document.main" %]/td td[% stick in related info here "document.sidebar" if it exists %]/td /tr /body That is, I have exactly one template that I apply to each document. Right now I do that using Sandwich and some pre-processing, but I'd much rather let a real template system do it so I can put parts in various places. Is TT the something that will let me do this without too much headache? I'm sure TT can do this. In addition, pretty much all the templating systems probably accomodate this. Under Mason this could be done very easily using the autohandler facility it provides. -dave /*== www.urth.org We await the New Sun ==*/
Re: dynamic vs. mostly static data
Vivek Khera [EMAIL PROTECTED] writes: Is TT the something that will let me do this without too much headache? Yes. Look at PRE_PROCESS and POST_PROCESS in the man page. Cheers, Dave -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: dynamic vs. mostly static data
head titleMy Site/title /head body tr td[% stick in body of article here "document.main" %]/td td[% stick in related info here "document.sidebar" if it exists %]/td /tr /body That is, I have exactly one template that I apply to each document. Right now I do that using Sandwich and some pre-processing, but I'd much rather let a real template system do it so I can put parts in various places. Is TT the something that will let me do this without too much headache? I'm sure TT can do this. In addition, pretty much all the templating systems probably accomodate this. Under Mason this could be done very easily using the autohandler facility it provides. Embperl (using the EmbperlObject handler) can do this in OO way, so you are not only able, to have one template, but also override parts of it for different parts of your side (as far as you need this). Additionaly the template can call methods inside the "document.main", so you are able to provide different method implentation with different documents. (e.g. for passing different titles to the template) See http://perl.apache.org/embperl/EmbperlObject.pod.cont.html for more information. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: dynamic vs. mostly static data
How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? If possible with your data, it'd probably be a good idea to generate static pages on-the-fly using mod_rewrite as in the related guide: http://www.engelschall.com/pw/apache/rewriteguide/#ToC33. You'll have to come up with a scheme to encode all query parameters in the URL and you can then just remove old pages periodically. It works fine here for a different application (thumbnails in arbitrary sizes generated on-the-fly). If that is out of the question, you can still use a simple filesystem-based caching mechanism (by mapping query args to unique, safe filenames) or something like IPC::Cache to cache the query results. -mjy -- Marinos J. Yannikos Preisvergleich Internet Services AG, Linke Wienzeile 4/2/5, A-1060 Wien Tel/Fax: (+431) 5811609-52/-55
Re: dynamic vs. mostly static data
On Tue, 7 Nov 2000, Marinos J. Yannikos wrote: If possible with your data, it'd probably be a good idea to generate static pages on-the-fly using mod_rewrite as in the related guide: http://www.engelschall.com/pw/apache/rewriteguide/#ToC33. If you have a caching proxy server running in front of your mod_perl server (like mod_proxy or Squid), you can just set Expires headers in your pages and this will be handled for you by the proxy. - Perrin
Re: dynamic vs. mostly static data
Matt Sergeant wrote: On Thu, 2 Nov 2000, Neil Conway wrote: I'm writing a web app in mod_perl, using a PostgreSQL database backend and HTML::Template. In looking for ways to optimize performance, I noticed that although my code is doing several (say, 4-5) database queries per handler/webpage, a large part of the data (~2 queries) is mostly static (it will change perhaps once per week, or once per month). It's obviously inefficient to run these queries on the database for every single request. How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? Also, this solution should work on any reasonably modern UNIX system (Win32 is not important for now). Along with all the other fine suggestions here, you might like to check out the Memoize module on CPAN. I don't think it yet offers a way to invalidate the cache, but I know that is planned. What about IPC::SharedCache ? This should allow you to cache stuff in IPC and updateit from outside apache via a crond job ? just my 2 euro's worth. Greg -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: dynamic vs. mostly static data
On Thu, 2 Nov 2000, Neil Conway wrote: I'm writing a web app in mod_perl, using a PostgreSQL database backend and HTML::Template. In looking for ways to optimize performance, I noticed that although my code is doing several (say, 4-5) database queries per handler/webpage, a large part of the data (~2 queries) is mostly static (it will change perhaps once per week, or once per month). It's obviously inefficient to run these queries on the database for every single request. How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? Also, this solution should work on any reasonably modern UNIX system (Win32 is not important for now). Along with all the other fine suggestions here, you might like to check out the Memoize module on CPAN. I don't think it yet offers a way to invalidate the cache, but I know that is planned. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: dynamic vs. mostly static data
On Thu, 2 Nov 2000, Neil Conway wrote:
Date: Thu, 2 Nov 2000 16:45:28 -0500
From: Neil Conway [EMAIL PROTECTED]
To: ModPerl List [EMAIL PROTECTED]
Subject: dynamic vs. mostly static data
I'm writing a web app in mod_perl, using a PostgreSQL database
backend and HTML::Template. In looking for ways to optimize
performance, I noticed that although my code is doing several
(say, 4-5) database queries per handler/webpage, a large part
of the data (~2 queries) is mostly static (it will change
perhaps once per week, or once per month). It's obviously
inefficient to run these queries on the database for every
single request.
How can I 'cache' this data so that all Apache children can
access it quickly? Is there a way to automatically update
this cache periodically (say every 10 minutes)? Also, this
solution should work on any reasonably modern UNIX system
(Win32 is not important for now).
I couldn't find this anywhere, but if someone tells me where,
I'd be happy to RTFM. Ask me if you need more info.
TIA,
Neil
neil,
i often do something like this where i allow each individual child
process to cache it's data. i do something like this:
package Apache::Foo;
use strict;
use Apache::Constants;
use POSIX 'strftime';
use constant CACHE_EXPIRES = 3600; # one hour
use vars qw[ %CACHE ];
%CACHE = ();
sub handler {
my $r = shift;
eval {
my $expires = $CACHE{'expires'} || 0;
if ($expires time) {
my @data = some routine ;
my $t = HTML::Template-new(filename = 'foo.tmpl',
die_on_bad_params = 0,
cache = 1);
$t-param('data', \@data);
$CACHE{'data'}= $t-output;
$CACHE{'expires'} = time + CACHE_EXPIRES;
}
$r-print($CACHE{'data'});
};
return print_err($r, $@) if $@;
return OK;
}
1;
btw, i'd really recommend you look into using Template Toolkit. it's a
much more powerful and flexible templating system than HTML::Template,
but i digress (and might start a flame war against myself by saying this).
hth,
ky
RE: dynamic vs. mostly static data
It might have been my Cache::Mmap module, which is ideal for this kind of thing. It depends on what your data looks like though, of course. On Thu, 2 Nov 2000 16:48:24 -0500 , Jerrad Pierce said: There is a query caching module someone posted here redently... Or was it proposed and beta-ish? Another thing you might consider doing is having a cron job do your periodic (10 min.) fetch and store it as a file somewhere... Then use SSI or some more mod_perl-ish means of including this static content... -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 02, 2000 4:45 PM To: ModPerl List Subject: dynamic vs. mostly static data I'm writing a web app in mod_perl, using a PostgreSQL database backend and HTML::Template. In looking for ways to optimize performance, I noticed that although my code is doing several (say, 4-5) database queries per handler/webpage, a large part of the data (~2 queries) is mostly static (it will change perhaps once per week, or once per month). It's obviously inefficient to run these queries on the database for every single request. How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? Also, this solution should work on any reasonably modern UNIX system (Win32 is not important for now). I couldn't find this anywhere, but if someone tells me where, I'd be happy to RTFM. Ask me if you need more info. -- Peter Haworth [EMAIL PROTECTED] "Writing for a penny a word is ridiculous. If a man really wants to make a million dollars, the best way would be to start his own religion." -- L. Ron Hubbard
RE: dynamic vs. mostly static data
Yeah that was it But you could probably even use Memoize for somehting like this? -Original Message- From: Peter Haworth [mailto:[EMAIL PROTECTED]] Sent: Friday, November 03, 2000 12:43 PM To: Jerrad Pierce; 'Neil Conway'; ModPerl List Subject: RE: dynamic vs. mostly static data It might have been my Cache::Mmap module, which is ideal for this kind of thing. It depends on what your data looks like though, of course. On Thu, 2 Nov 2000 16:48:24 -0500 , Jerrad Pierce said: There is a query caching module someone posted here redently... Or was it proposed and beta-ish? Another thing you might consider doing is having a cron job do your periodic (10 min.) fetch and store it as a file somewhere... Then use SSI or some more mod_perl-ish means of including this static content... -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 02, 2000 4:45 PM To: ModPerl List Subject: dynamic vs. mostly static data I'm writing a web app in mod_perl, using a PostgreSQL database backend and HTML::Template. In looking for ways to optimize performance, I noticed that although my code is doing several (say, 4-5) database queries per handler/webpage, a large part of the data (~2 queries) is mostly static (it will change perhaps once per week, or once per month). It's obviously inefficient to run these queries on the database for every single request. How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? Also, this solution should work on any reasonably modern UNIX system (Win32 is not important for now). I couldn't find this anywhere, but if someone tells me where, I'd be happy to RTFM. Ask me if you need more info. -- Peter Haworth [EMAIL PROTECTED] "Writing for a penny a word is ridiculous. If a man really wants to make a million dollars, the best way would be to start his own religion." -- L. Ron Hubbard
RE: dynamic vs. mostly static data
There is a query caching module someone posted here redently... Or was it proposed and beta-ish? Another thing you might consider doing is having a cron job do your periodic (10 min.) fetch and store it as a file somewhere... Then use SSI or some more mod_perl-ish means of including this static content... -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 02, 2000 4:45 PM To: ModPerl List Subject: dynamic vs. mostly static data I'm writing a web app in mod_perl, using a PostgreSQL database backend and HTML::Template. In looking for ways to optimize performance, I noticed that although my code is doing several (say, 4-5) database queries per handler/webpage, a large part of the data (~2 queries) is mostly static (it will change perhaps once per week, or once per month). It's obviously inefficient to run these queries on the database for every single request. How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? Also, this solution should work on any reasonably modern UNIX system (Win32 is not important for now). I couldn't find this anywhere, but if someone tells me where, I'd be happy to RTFM. Ask me if you need more info. TIA, Neil -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed "The superior man understands what is right; the inferior man understands what will sell." -- Confucius
Re: dynamic vs. mostly static data
"NC" == Neil Conway [EMAIL PROTECTED] writes: NC How can I 'cache' this data so that all Apache children can NC access it quickly? Is there a way to automatically update write a cron job that republishes these pages as plain HTML and link to those instead of the dynamic program. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: dynamic vs. mostly static data
Jerrad Pierce wrote: There is a query caching module someone posted here redently... Or was it proposed and beta-ish? Another thing you might consider doing is having a cron job do your periodic (10 min.) fetch and store it as a file somewhere... You can use the module Storable to store Perl data structures to a file. Then your Apache children can read the file as a ready to use data structure. Then use SSI or some more mod_perl-ish means of including this static content... >-Original Message- >From: Neil Conway [mailto:[EMAIL PROTECTED]] >Sent: Thursday, November 02, 2000 4:45 PM >To: ModPerl List >Subject: dynamic vs. mostly static data > > >I'm writing a web app in mod_perl, using a PostgreSQL database >backend and HTML::Template. In looking for ways to optimize >performance, I noticed that although my code is doing several >(say, 4-5) database queries per handler/webpage, a large part >of the data (~2 queries) is mostly static (it will change >perhaps once per week, or once per month). It's obviously >inefficient to run these queries on the database for every >single request. > >How can I 'cache' this data so that all Apache children can >access it quickly? Is there a way to automatically update >this cache periodically (say every 10 minutes)? Also, this >solution should work on any reasonably modern UNIX system >(Win32 is not important for now). > >I couldn't find this anywhere, but if someone tells me where, >I'd be happy to RTFM. Ask me if you need more info. > >TIA, > >Neil > >-- >Neil Conway [EMAIL PROTECTED]> >Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc >Encrypted mail welcomed > >"The superior man understands what is right; > the inferior man understands what will sell." > -- Confucius > -- --- Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 --- -- Don't make me use uppercase
