|
abaxaba has asked for the wisdom of the Perl Monks concerning the following question:
Sort of a hodgepodge of questions here:
As I noted here, I do NOT have mod_perl access with my ISP. To complicate matters, I'm working on a CGI/mysql application that must run on various platforms (*NIX, Windose/ActiveState, and possibly OS-X). Assuming $]>=5.6 is a very bad thing in this instance. 5.005 is more like it.
For the sake of speed, I'd like to create persistent DBI handles, and possibly persistent statement-handles, with some sort of "?" placeholders to handle the dynamics of the various select/insert/update queries.
Looking at CPAN, usenet, and the Monestery yields a basketful of options. But I'm not sure what the best would be for my needs:
| I would like for the necessary module(s) to be pure-perl, for ease of installation (eg, copy someFile.pm) |
| Obviously, it has to handle blessed refs |
| I've not determined a storage method yet, so I'd like it to be concise, just to be safe. One thought I've had was to use Crypt::??? or some funky sprintf/pack combo to garble/encrypt the string, and store it in a cookie. |
| If all of my blessed objects are "the same" (ie - same dbName, userName, password for DBI->connect), couldn't I just store the serialized strings in a .pl file as scalars, read them in via require, and thaw/eval as needed? Of course, this file would be above the document root. |
| And of course, speed is paramount. If it weren't, I wouldn't be persisting! |
Any assistance, pointers, literature-links, etc, regarding this manner, as always, is greatly appreciated.
ÅßÅ×ÅßÅ
"It is a very mixed blessing to be brought back from the dead." -- Kurt Vonnegut
|
|
Re: /^mod_perl/ && Persistent DBI
by IlyaM (Parson) on May 29, 2002 at 13:19 UTC
|
There is no point in having persistent connections in CGI/MySQL configuration. Unlike Oracle and many other SQL servers database handle initialization is very cheap in MySQL. I bet you will find that most overhead comes not from database handle initialization but from loading DBI and all other modules in your CGI script.
But really only benchmarking can show it. BTW have you tried to benchmark your code? Benchmarking may help you to improve your code in terms of perfomance much better than any blind optimization of some things you suspect to be slow.
--
Ilya Martynov
(http://martynov.org/)
| [reply] |
Re: /^mod_perl/ && Persistent DBI
by derby (Abbot) on May 29, 2002 at 13:08 UTC
|
abaxaba,
I hate to throw cold water on your ideas but without some type of "across-request/in-memory" mechanism (ala mod_perl or fastcgi), persistence of
dbh handles is quite near impossible (at least on *nix, I'm
not sure about win32 or OS-X).
If you have to deal with a traditional CGI environment, (one request per process), serialization of your connection class is actually going to slow you down (overhead of serialize/deserialize plus the need to reconnect to the
db).
That being said, there are still some techniques you can use. If you know you're going to have a large set of "the
same" sql queries, you could offline bake the html and serve up static html. If you're script does a large number of similar sql calls, placeholders may help. Not all drivers or servers database servers truely support placeholders.
-derby
update: ++IlyaM for Re: /^mod_perl/ && Persistent DBI. | [reply] |
•Re: /^mod_perl/ && Persistent DBI
by merlyn (Sage) on May 29, 2002 at 15:26 UTC
|
Do not invent protocols. Use SOAP::Lite to set up a mini-SOAP HTTP server on the first hit, then subsequent hits will reuse that server. Have it time out after some number of minutes, and you automatically get lightest weight persistence.
You can use HTTPS to talk to the mini-server, and certificates to ensure client authenticity. That should handle your eavesdropping/authentication issues.
-- Randal L. Schwartz, Perl hacker | [reply] |
|
|
| [reply]
[d/l] |
|
|
Google searching Soap::Lite returns the Soap::Lite homepage, which explains the protocol & design patterns...
| [reply] |
|
|
