I i'm right, every DB function begins by a $dbh=&C4Connect. Connecting to a DB is a HIGH time-cost function. 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. 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) -- Paul
I i'm right, every DB function begins by a $dbh=&C4Connect. Connecting to a DB is a HIGH time-cost function. 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. 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)
My solution would be to create a global $dbh in the .pm that has the C4Connect sub. You can get a .pm to execute some code at the time that it is loaded (see package Constructors and Deconstructors in the perl man pages)- which would allow you to connect to the database. And when the script ends, you can disconnect from the database. I don't know if this is the best solution, but at least it would get it down to one connect per script call. Gynn.
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.
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 :-) - Alan ---- Alan Millar --==> am12@bolis.com <==--
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
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.
Careful: mod_perl+apache leads to two things needing to be done.... (a) we sacrifice the (at least theoretical) ability to be truly webserver-app-choice independent (Bigger question: How important is that independence) (b) Nick/documentation writers :) need to be told to change the manual to reflect a change in (a).
On Tue, Jun 11, 2002 at 09:16:53AM -0400, Nicholas Rosasco wrote:
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.
Careful: mod_perl+apache leads to two things needing to be done.... (a) we sacrifice the (at least theoretical) ability to be truly webserver-app-choice independent (Bigger question: How important is that independence)
In my opinion, fairly important. Even someone who commits to working with only one method of a solution, and "doesn't care" about being portable, eventually will find out that they've worked themselves into a corner when an upgraded and/or altered version of their one solution comes out and they have to retrofit. Abstraction is a Good Thing. I've never used mod_perl. Is there a way we can be "mod_perl friendly" and still work just fine with the current CGI methods? Perhaps the abstraction can take place within C4Connect, which could accomodate for the type of environment present. I still think the handle should be passed to individual subroutines, though. - Alan ---- Alan Millar --==> am12@bolis.com <==--
On Tue, 11 Jun 2002, Alan Millar wrote:
On Tue, Jun 11, 2002 at 09:16:53AM -0400, Nicholas Rosasco wrote:
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.
Careful: mod_perl+apache leads to two things needing to be done.... (a) we sacrifice the (at least theoretical) ability to be truly webserver-app-choice independent (Bigger question: How important is that independence)
In my opinion, fairly important. Even someone who commits to working with only one method of a solution, and "doesn't care" about being portable, eventually will find out that they've worked themselves into a corner when an upgraded and/or altered version of their one solution comes out and they have to retrofit.
Abstraction is a Good Thing.
I've never used mod_perl. Is there a way we can be "mod_perl friendly" and still work just fine with the current CGI methods?
Yes, there is ... it's using Apache::Registry to run the scripts (which makes them rather like a plain CGI only faster. It does however preload the scripts into the Apache server -- so that we have to be more careful when writing code (silly things like not closing filehandles or having global variables all over the place) which a straight CGI script won't flinch at will cause problems when run in the stricter environment of Apache::Registry (using diagnostics and strict pragmas will get you 99% of the way to mod_perl safety). Using Apache::DBI is something that we can do without changing the scripts (accept as noted above). It will intercept the DBI connect and disonnects and replace them with connections to a pool of existing connections.
Perhaps the abstraction can take place within C4Connect, which could accomodate for the type of environment present. I still think the handle should be passed to individual subroutines, though.
Even if we do decide to let bigger users go the Apache::DBI route minimizing the number of connect/disconnect calls we use would be a good thing. I think passing a handle within a module makes a lot of sense. -pate
- Alan
---- Alan Millar --==> am12@bolis.com <==--
_______________________________________________________________
Multimillion Dollar Computer Inventory Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar
_______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
participants (5)
-
Alan Millar -
Gynn Lomax -
Nicholas Rosasco -
Pat Eyler -
paul POULAIN