[cgiapp] cached DBI connections with cgiapp/fastcgi

[Michael Peters]

Benjamin Hitz wrote:
> Well... OK, it's not MUCH slower, but we also 
> added some new
> modules that use DBIx::Class... and on a 120 table database THAT is slow 
> to load (2sec).
> 
> Dumping DBIx::Class would also be an option, but it's still not 
> particularly zippy with plain CGI/
> (main page does ALOT of queries, and they are often quite complicated)

Are you loading your DBIx::Class classes before you start up? Depending on your setup it might be 
querying the database tables to determine which columns exist, etc so set up your classes. So if you 
preloaded that you wouldn't get that hit on every request. I don't use DBIx::Class but I assume it's 
like other ORMs.

> Will consider this.  The only globals are:
> a) a couple of constant hashes
> b) a bunch of "use constants"
> a) C::A::P::TT->tt_config*
> 
> Can you leave global constants here, I do I have to shove them into the 
> object?

Constants should be just fine. And anything attached to a namespace is probably ok too. Just as long 
as your code isn't dependent on those globals being unitialized on every request. But if you can run 
  it under fastcgi, I assume you can run it under mod_perl very easily.

> * I call tt_config as a class method as recommended in the POD section 
> "SINGLETON SUPPORT".
> It mentions:
> "So to improve the efficiency of Template Toolkit, we should keep the 
> object (and hence all the compiled templates) in memory across multiple 
> requests. This means you only get hit with the startup cost the first 
> time the TT object is created"
> 
> But I don't see how putting this in the superclass actually does this, 
> in a vanilla (NON CACHED) CGI app where a C::A object is instantiated, 
> ->run() and then destroyed.  What difference does it make under 
> namespace the tt object exists?  Assuming you don't run tt_config at 
> each level of the hierarchy (which you would have to be pretty silly to do)

If you call it as a class method then the TT object is associated with the Class (which persists 
between requests in a persistant environment) not the object (which does not persist between requests).

> As a point of clarification, most of the relevant C:A objects are in my 
> system are:
> 
> WWW::Reports::LocusReport::LocusSummary ISA LocusReport
> WWW::Reports::LocusReport:: ISA Reports
> WWW::Reports ISA CGI::Application
> 
> yay extraneous plural!
> 
> So is the "singleton support" comment only relevant in a cached env like 
> mod_perl or FCGI?

Yes.

-- 
Michael Peters
Plus Three, LP