On Mon, 10 Jun 2002, Alan Millar wrote:
On Mon, Jun 10, 2002 at 10:52:42PM +0200, paul POULAIN wrote:
I i'm right, every DB function begins by a $dbh=&C4Connect. Connecting to a DB is a HIGH time-cost function.
I agree. The current method works fine for small, lightly loaded systems. If we want Koha to scale, and want it to be portable to other DB engines where the DB open may be an even bigger performance hit, we should change the current practice.
One solution (at least on the high end) is to use mod_perl and Apache::DBI to intercept the connect and disconnect calls and use an existing pool of connections instead. mod_perl safety in the rest of the scripts (running them with Apache::Registry as opposed to making them handlers), is going to be a big part of making the system scale. (Being prepared to run Koha as a two-tiered system and planning on spreading the app over several servers is going to be another bit to look at.) The real trick is going to be in ensuring that we're able to use tricks like this without requireing that the small libraries (and home libraries) don't need to take on the overhead of mod_perl.
The solution to this problem would be to have only one $dbh=&C4Connect at the beginning of every .pl script, this $dbh variable being used by every sub.
I think this is where we need to go. Yes, it is the most work, but I'd rather see us phase in the right solution over time than change a bunch of subroutines quickly for a short-sighted solution.
One solution would be to rebuild all sub calls to add a dbh parameter, but i'm sure there is a solution to declare a global variable, which would be used if there is no "my $dbh" in the .pm sub... What's the best solution in Perl to do this ? ("our" may be used with packages, but what i want is to have the C4Connect at the beginning of every .pl script)
I'd like to avoid undocumented side effects in subroutines. What happens at some point in the future when you might want two different databases open, but you can only use the subroutine on one of them because the database handle depends on a global variable with a fixed variable name? "Oh, we'll never need that...." :-)
I just spent the last week unravelling a script that didn't do "use strict", and chasing down the side effects of undeclared variables and global variables used in subroutines was a mess. Let's not do more of that :-)
Yes, 'down this path lies madness'. Down this path also lie hideous debugging and maintenance nightmares and huge mod_perl issues! Let's stick to the connect and disconnect per module and look to Apache::DBI to help with the *really* big sites. -pate
- Alan
---- Alan Millar --==> am12@bolis.com <==--
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel