Re^2: Command line Persistent DBI connections

pperl looks very interesting, mod_perl for command the command line. can you use that to test modperl scripts?

the reason i ask about the crons is if you have a lot of web servers all running multipe crons against a single db then a lot of connections can start to occur.

I suppose the frequency of the crons in question will dictate the need for persistance. if it they are every minute it might be worthwhile

cheers

Comment on Re^2: Command line Persistent DBI connections

Replies are listed 'Best First'.
Re^3: Command line Persistent DBI connections by Thilosophy (Curate) on Dec 15, 2004 at 05:05 UTC
pperl looks very interesting, mod_perl for command the command line. can you use that to test modperl scripts? Not really. If your modperl script is just "CGI on steroids" (still using the standard CGI interface) you test it by running it as plain CGI. If your modperl script is making use of Apache's internal interfaces, you have to have mod_perl to test it. the reason i ask about the crons is if you have a lot of web servers all running multipe crons against a single db then a lot of connections can start to occur I would say having a lot of crons on a lot of servers is rather a reason to not have persistant connections, because then you have a lot of persistent connections hanging around mostly idle. If you want all your cron jobs (on all servers) to share the same connection, you could move the logic into a mod_perl script that you poll via LWP as suggested by Perrin. This will probably not work very well if the query takes a lot of time. How many servers are we talking here? Go with new connections every time. Chances are your database can handle it just fine. The actual queries are likely to place more of a burden on it than establishing the connections anyway.	[reply]
Re^4: Command line Persistent DBI connections by hakkr (Chaplain) on Dec 17, 2004 at 10:08 UTC
Between 10 -20 servers, I think you are right using some sort of messaging webservice style solution is probably better than connecting directly to the database anyway. Will allow all the scripts to be in one place as well which is always good cheers	[reply]