Mark Stosberg wrote:
> Hello,
>
> I just had this idea about easy caching in CGI::Application and wanted
> to share some ideas.
>
> The core concept is that run modes could marked as cacheable with simple
> attributes:
>
>
> sub run_mode_name : Cacheable('10 min') {
> # your run mode here
> }
>
> The first time the run mode is called, it would really run.
> For the next 10 minutes, a cached page would be returned.
>
> Further, every time the run mode is activated, the appropriate headers
> would be added to allow browser-side caching as well.
>
> This could be useful for complex reports, but would probably be the
> Wrong Solution if the query string or cookie could affect the outcome.
Or you could just make the cache key based on the query string and/or
cookies.
> There would also be a "config_caching()" method that could be used in
> setup or cgiapp_init to set up details for which backend and storage to
> use.
>
> Some other ideas:
>
> - a global option to mark all run modes as cacheable
> - a global option to turn off caching, which makes debugging easier.
>
>
> These are just brainstorms. I don't claim to be an expert on website
> performance or caching. (And I haven't done any benchmarking about
> run-mode level caching versus just caching expensive DB queries).
>
> One thing I have noticed though: Even if the database and templating
> engines are fast enough, under heavy load it's possible to run out of
> database connections.
A db handle is tied to the process. So even if you don't use the handle,
if that process serves up a request, that handle cannot be used
somewhere else. This means that if you have a persistant DB handle
(using something like Apache::DBI under mod_perl) you might exceed your
DB limit earlier than expected, even though the DB load is minimal.
In my experience, if the load is heavy enough to run out of database
connections then you should be using a proxy in front of that site. This
let's you have more concurrent requests than DB connections, and your
heavier processes (usually mod_perl, etc) are freed up as soon as they
are finished generating the content rather than waiting on user's
potentially slow connections.
I agree that caching would be cool, but I'm not sure it would save DB
handles in a lot of situations (except to just make the processing of
the run mode faster).
> Caching could shift the load of the identical database queries being run
> repeatedly.
>
> Perhaps making caching easy in this way is the wrong solution because it
> could encourage over-engineering which may actually slow down the common
> case, instead of adding extra performance the few specific cases where
> it's actually needed.
I think as long as the caveats are documented and it's explained where
it would be a good fit, and where it would not, then it's probably ok.
I also think having caching on the run mode level would help CAF out
with 'Embedded Components'. This way you could cache some of the
semi-dynamic portions of page but putting it into another 'Cacheable'
run mode.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
