MySQL Forums
Forum List  »  Perl

DBI makes every operation a separate exchange
Posted by: Garth Snyder
Date: January 27, 2007 07:54PM

This really seems like a noob question to me, but I'm afraid that my efforts to find an existing answer have been fruitless.

I'm inserting a series of records into a remote MySQL database through Perl's DBI library (using DBD::mysql), and although everything works correctly, I've noticed that each insertion is performed as a separate network exchange (as verified with a network sniffer). This makes the procedure pretty slow (~20 seconds) even though only a few hundred simple records are involved.

I'd post the code, but really, it's about as straightforward as an INSERT gets. I've tried a variety of forms (prepare, bind_param_array, execute_array), but although they all work, they all yield the same network behavior and poor performance. Same with DELETEs.

As near as I can tell from a quick review of the DBI code, these variants are all just sugar that funnel into the generic execute() method.

My question is: is this normal and irremediable? Despite a half-day of searching in various forums, including this one, I haven't been able to turn up any discussion of this issue at all. Very strange - I would have thought this would be a basic implementation issue that just about everyone using DBI would encounter.

Configuration: Windows XP with Cygwin. Standard installation of DBI via cpan command. Manual installation of MySQL with local compilation as required to get DBD::mysql to install cleanly, but the actual MySQL server is remote. All packages and tools are up to date.

Any insight you can offer would be most appreciated. Thanks!

Options: ReplyQuote


Subject
Written By
Posted
DBI makes every operation a separate exchange
January 27, 2007 07:54PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.