ryddler has asked for the wisdom of the Perl Monks concerning the following question:

I've been working on an ASP using an Access 2K DB, and have been suffering incredibly bad performance issues. Using the following snippet, I was able to determine that it was taking between 30 and 40 seconds just to connect to the DB, let alone perform any queries. 

use DBI;

$start = time;
$dbh_metro = DBI->connect("dbi:ADO:metro");
$finish = time - $start;
$Response->write("<CENTER><H2>took $finish seconds to connect DB</H2><
+/CENTER>\n");

[download]

Then, using this snippet, I was able to drop the connection to nearly 0 (zero) second connection times. 

$start = time;
$dbh_metro = $Server->CreateObject('ADODB.Connection');
$dbh_metro->Open("metro");
$finish = time - $start;
$Response->write("<CENTER><H2>took $finish seconds to connect DB</H2><
+/CENTER>\n");

[download]

Has anyone else experienced any issues like this? Any idea why DBI would be so dog-slow? I was hoping to program the ASP with a Perl mindset and style, but if DBI is going to be so slow I'll be forced to use the M$ object syntax instead.

As an aside, does anyone have any good Perl based ASP links?

ryddler

Replies are listed 'Best First'.
Re: ADO (DBI) vs ADODB.Connection
by repson (Chaplain) on Jan 10, 2001 at 08:36 UTC
    Another couple of things to try:
    Can you use ODBC instead of ADO, I know I've been able to create access connections with DBD::ODBC without waiting too long, maybe just try it for comparison.
    You can also try connecting to the database file on disk, without actually even needing access installed, which you can read about in the docs for DBD::ODBC.
[reply]

      Thanks for the suggestion. I plugged in "ODBC" into the first listing from above like below, and my connection times dropped to 0 (zero) like those of the second listing above. 

      use DBI;

$start = time;
$dbh_metro = DBI->connect("dbi:ODBC:metro");
$finish = time - $start;
$Response->write("<CENTER><H2>took $finish seconds to connect DB</H2><
+/CENTER>\n");

      [download]

      So this means that myself and anyone else who wishes to use PerlScript vs VB writing ASP's should be using the ODBC with DBI instead of ADO. Let's look at those numbers again...

      DBD::ODBC 0 - 1 second Perl Style DB access methods :-)
      DBD::ADO 30 - 40 seconds Perl Style DB access methods :-)
      'ADODB.Connection' 0 - 1 second MS Style DB access methods :-(

      Update: After some serious hair pulling about why my machine was unexpectedly rebooting itself whenever I tried to compile anything, or run the Beta of Komodo, I discovered that the antivirus program was causing not only the reboot problems, but actually caused the ADO time to increase as shown in the chart. Actual ADO times without A/V running are the same as the other two methods.

      ryddler

[reply]
[d/l]
        I've noticed this before comparing Win32::ODBC and ADODB.Connection

        I haven't got around to using the (more perlish way) of DBI, because I haven't had the time. But where I work, and the projects I've been working on using the ADO component with OLE has not been a problem. (I suppose this is mainly because everyone else here uses that with ASP - I'm in the minority using Perl.

        Still I want to get round to using DBI, so this post has been useful to me because I'll try out DBD::ODBC first!
[reply]
Re: ADO (DBI) vs ADODB.Connection
by wardk (Deacon) on Jan 10, 2001 at 05:39 UTC

    It appears your DBI-less second snippet IS perl. I think you can still program with a perl mindset and style, just perhaps not use the database connection in snippet one.

    on Perl and asp links, I'd check with Activestate.com, they are taking on making perl an option within the ms environment.

    You know, if you use SQL Server you can use Win32::ODBC, which is not unlike regular old DBI. MS Access...man I'm glad I can't feel your pain :-)

    good luck!

[reply]

      MS Access...man I'm glad I can't feel your pain :-)

      Fortunately the production DB isn't going to be Access. Not sure what it will be yet, we're in the process of building testbeds to try out some trial DBMS's to replace our current DBMS which is Pervasive / Btrieve (talk about feeling pain ;)

      My concern was/is that the interface seemed to be slower than would be acceptable. If I were designing for myself I'd be using a MySQL DB, but at work the company needs technical support offered by one of the mainstream databases.

      ryddler

[reply]

        I think if you are selling perl, then use the fastest access method available. But any decent or lack of performance from Access isn't likely very valuable information if the goal is a multi-user relational database.

        Since Access is in house and thought to be usable, I bet you could get support for at least using SQL Server. I have used Perl in combination with SQL Server for a Customer Service website (Concur) and it's a very decent combination. You could use Win32::ODBC to make the database connection and it's very fast and a great way to show off the value of Perl on a Windows system.

        Since SQL Server is so easy to get setup (and I suspect you'd get support internally to make it happen), I would advise avoiding Access and going direct to SQL Server (or Oracle if possible). Another option to Access would be Sybase SQL Anywhere (formerly Watcom SQL) which is a real RDBMS for smaller MySQL type applications.

        of course using Perl instead of ASP, even Access can be "fun"...relatively speaking ;-)

[reply]
        Well if you are unsure of what DB you are going to end up using I would suggest using DBI and then use DBD::ODBC or DBD::ADO to connect to Access. This should allow you to use almost any DB.

        --BigJoe

        Learn patience, you must.
        Young PerlMonk, craves Not these things.
        Use the source Luke.
[reply]

Back to Seekers of Perl Wisdom