Use CGI or DBI (or both) built-in cacheing techniques. Basically, all you do is specify the module to use cacheing and it will do it automatically. This will NOT dramatically increase the number of users able to connect to the database but will certainly help to speed things up and take care of repeated queries (to its best extent). Some options i the modules are also available for tweaking. i hope you're using mod_perl or fastcgi! | [reply] |
As far as I know (and I've really looked for this answer in the ActiveState documentation) IIS/Perlscript will not cache any of global data or pre-compiled scripts. Every time you invoke a page it gets compiled and executed again and there's no way to get around this other than resorting to PerlEx, which comes with it's share of obscurities (I, for instance, was unable to make it stop generating http headers in the ASP like embedded perl option, which prevented me from sending cookies, which is an important lack, and PerlEx comes with no source). The fact that you can't cache globals under IIS/Perlscript is what prevents you from keeping connections alive. Given this I believe that AgentM's is not a real solution to the problem. runrig's suggestion, which relies on a perl wrapper around microsoft persistant objects, seems like the way to go for me. If your DB tables are small enough, and most of your traffic is read only, I could suggest you putting your tables into hashes and freezing them into the Application object, which is a horrible hack, but can be a lot faster than querying the database. You can see a discussion on this at this node. | [reply] |
According to this ADO caches the connection object so consider DBD::ADO | [reply] |
Also, check out
PerlEx
from the friendly ActiveState folks. Like
mod_perl for NT (IIS, O'Reilly, Netscape...) --
at least until mod_perl on NT gets full threading
capabilities under Apache 2.
| [reply] |