Re: [cgiapp] RFC: CGI::Application::RunModeCache
On Wed, 12 May 2004 15:17:17 -0300, Brian Cassidy wrote: Hi Folks CGI::App which uses Gedcom.pm. Some of its operations can be quite lengthy, thus caching would be wise. Just for the record, the Gedcom mailing list is accessible via: http://www.miskatonic.org/pg/ -- Ron Savage, [EMAIL PROTECTED] on 14/05/2004. Room EF 312 Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia Phone: +61-3-9251 7067, Fax: +61-3-9251 7604 http://www.deakin.edu.au/~rsav - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::RunModeCache
Quoting Brian Cassidy [EMAIL PROTECTED]:
Hi All,
Something I've been wanting for a while now is a generic caching system to
plug in to CGI::Application. For example, I have a CGI::App which uses
Gedcom.pm. Some of its operations can be quite lengthy, thus caching would
be wise.
The following is what I might consider a workable first step.
Great concept! I really like it.
I do have a couple of concerns/comments though:
- you use exit() to short circuit the execution of the program. In a CGI
environment that will probably be OK, but in persistant environments that may
cause problems. I'm pretty sure that mod_perl overrides CORE::exit so that the
program doesn't end, but I'm not so sure about FastCGI and SpeedyCGI. TO get
around it would probably require a change to CGI::Application though.
- you have effectively hijacked the prerun and postrun methods which means they
are unavailable to any sub/super classes. This brings me back to my request
from many months ago for the ability to register prerun and postrun hooks so
that you can have multiple prerun/postrun execution points (patch available
here:
http://cees.crtconsulting.ca/perl/patches/CGI-Application-3.21.callbacks.patch)
. As an interim solution you may want to include a comment in your docs that
lets people know they need to add $self-SUPER::cgiapp_postrun to their own
custom cgiapp_postrun method if they use it (same for cgiapp_prerun). Otherwise
your cache code stops working.
- Is there a specific reason you are using Data::Dumper to flatten the object?
I would think that Storable would be a better choice, since it removes the need
for the 'eval'. Not a big deal though.
- maybe a useful addition could be the ability to decide whether a runmode is
cachable from within the runmode itself. something like this would do:
sub my_runmode {
my $self = shift;
$self-cachable(0); # This runmode IS NOT cachable
# - or -
$self-cachable(1); # This runmode IS cachable
}
It would make sense to make the default be that all runmodes are cached, but
this would allow the runmode to decide whether it is cachable. It looks like
this is possible already through a custom cache_key method, but this might be
another simple way to achieve it.
Overall it looks like a great module that I hope to see on CPAN someday soon.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::RunModeCache
On Wed, 12 May 2004, Brian Cassidy wrote: Something I've been wanting for a while now is a generic caching system to plug in to CGI::Application. For example, I have a CGI::App which uses Gedcom.pm. Some of its operations can be quite lengthy, thus caching would be wise. Why not just Memoize the methods that access Gedcom.pm? It's not obvious to me that caching the entire page is right choice here. Often-times an application will include dynamic components and static cacheable components on the same page. Cache::FileCache is used by default, but you can pass in your own Cache::* to replace it. The Cache::* modules are quite slow in my experience. I've used Cache::Mmap for disk-based caching and I've heard Cache::FastMmap is even better. -sam - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::RunModeCache
On Thu, 13 May 2004, Cees Hek wrote: Memoize is mainly used in persistant environments. Although many people use mod_perl or SpeedyCGI with C::A, we are talking about CGI::Application, so a disk based cache makes sense as a default. Memoize can do disk-based caching. From the docs: tie my %cache = 'GDBM_File', $filename, O_RDWR|O_CREAT, 0666; memoize 'function', SCALAR_CACHE = [HASH = \%cache]; But really, if you're worried about performance and you're not using a persistent environment... Well, you've got bigger problems than a couple slow run-modes! -sam - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] RFC: CGI::Application::RunModeCache
Hi Cees, -Original Message- - you use exit() to short circuit the execution of the program. In a CGI environment that will probably be OK, but in persistant environments that may cause problems. I'm pretty sure that mod_perl overrides CORE::exit so that the program doesn't end, but I'm not so sure about FastCGI and SpeedyCGI. TO get around it would probably require a change to CGI::Application though. I was thinking that might be an issue -- but I haven't been able to find any information that might say either way. As far as I can tell there's no way to short-circuit a CGI::App in a clean way. - you have effectively hijacked the prerun and postrun methods which means they are unavailable to any sub/super classes. This brings me back to my request from many months ago for the ability to register prerun and postrun hooks so that you can have multiple prerun/postrun execution points (patch available here: http://cees.crtconsulting.ca/perl/patches/CGI-Application- 3.21.callbacks.patch) . As an interim solution you may want to include a comment in your docs that lets people know they need to add $self-SUPER::cgiapp_postrun to their own custom cgiapp_postrun method if they use it (same for cgiapp_prerun). Otherwise your cache code stops working. Right. In order for these methods to be called automatically, I've had to use pre-existing and possibly already overridden subs. Ideally I could just tack on to the app flow, but that would require your patch. :) - Is there a specific reason you are using Data::Dumper to flatten the object? I would think that Storable would be a better choice, since it removes the need for the 'eval'. Not a big deal though. No particular reason other than it was there. - maybe a useful addition could be the ability to decide whether a runmode is cachable from within the runmode itself. something like this would do: Yeah, that seems like a more obvious approach. I'll add that in. Thanks! -Brian http://www.gordano.com - Messaging for educators. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] RFC: CGI::Application::RunModeCache
Hi Sam, -Original Message- Why not just Memoize the methods that access Gedcom.pm? It's not obvious to me that caching the entire page is right choice here. Often-times an application will include dynamic components and static cacheable components on the same page. Well, you're probably right. Since I don't have any dynamic components in the app to speak of, that aspect never crossed my mind. I'll have to think about it -- and I'll probably come out to the conclusion that in a lot of situations the caching in my module is happening at the wrong level. Cache::FileCache is used by default, but you can pass in your own Cache::* to replace it. The Cache::* modules are quite slow in my experience. I've used Cache::Mmap for disk-based caching and I've heard Cache::FastMmap is even better. I'll check 'em out. Thanks! -Brian http://www.gordano.com - Messaging for educators. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
