Re: DBI speed up needed on MySQL

in reply to DBI speed up needed on MySQL

There's not enough information to properly fix your problem, but here are a few thoughts. I guess the most obvious question is about your use of "SELECT *". Do you really need to select all of those fields? That's 8 million fields that you are selecting. (Personally, I'm rather suspect about any table that requires 200 fields (it suggests to me that it's not designed properly.) And what are you printing to? Are you sending the data to a socket, to STDOUT, to a file? Those can all have significant performance issues. If you're printing to STDOUT, try printing to a file and see how much faster it is.

And yes, fetchrow_arrayref is faster. Perhaps you can use that and a hash slice? I haven't benchmarked that, so I can't comment on the performance aspect. However, you say that you need to have $result as a hashref. Why?

Last question: are you sure those indexes are useful? The SQL statements that you use can suggest indexes you might need, but the data is important, too. Not every field will benefit from an index. Also, have you used a profiler to find out where your SQL is really bottlenecking? (I assume MySQL will let show you query plans). The statement itself seems pretty simple, but whether you're IO bound or CPU bound could make a difference. Talk to a MySQL DBA about this issue. A good DBA is worth their weight in gold.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re: DBI speed up needed on MySQL

Replies are listed 'Best First'.
Re^2: DBI speed up needed on MySQL by jhourcle (Prior) on May 08, 2005 at 19:32 UTC
To build on what ovid said, you might want to look to see how much of the time taken was from mysql. Dump the SQL that perl is using for its query, and then run that in the mysql client. If that takes a significant time, you might take a look at EXPLAIN. It's also necessary to ANALYZE your tables when they change significantly, so that the database can determine if the indexes are going to be a benefit or not. (it can be faster to not use an index unless you're throwing away the majority of the records, as you require more table reads... for oracle, I've heard that number is between 5 to 20% of the records kept.. so if you're throwing away less than 4/5 of the records, a full table scan may be the way to go. Memory sizing of the system can also be important -- out of the box, mysql uses very little memory (in my opinion). If you have a 2GB dedicated server, it does no good if mysql is told to only use 256MB. (it might be 384MB as the default...still rather small for some people). Anyway, if you find that the perl process is taking 30 minutes, but it's only taking 5 minutes for mysql to do its work, then you'll want to look at the Perl side of things. If it's taking 25 minutes in MySQL, then you'll want to look at adjusting the SQL statement, or tuning the database. If it's somewhere in between, well, pick one, and if that doesn't get enough time out to be acceptable, tune the other side, and keep going back and forth 'till it meets your goal time.	[reply]

Replies are listed 'Best First'.

Re^2: DBI speed up needed on MySQL
by jhourcle (Prior) on May 08, 2005 at 19:32 UTC

To build on what ovid said, you might want to look to see how much of the time taken was from mysql. Dump the SQL that perl is using for its query, and then run that in the mysql client. If that takes a significant time, you might take a look at EXPLAIN. It's also necessary to ANALYZE your tables when they change significantly, so that the database can determine if the indexes are going to be a benefit or not. (it can be faster to not use an index unless you're throwing away the majority of the records, as you require more table reads... for oracle, I've heard that number is between 5 to 20% of the records kept.. so if you're throwing away less than 4/5 of the records, a full table scan may be the way to go.

Memory sizing of the system can also be important -- out of the box, mysql uses very little memory (in my opinion). If you have a 2GB dedicated server, it does no good if mysql is told to only use 256MB. (it might be 384MB as the default...still rather small for some people).

Anyway, if you find that the perl process is taking 30 minutes, but it's only taking 5 minutes for mysql to do its work, then you'll want to look at the Perl side of things. If it's taking 25 minutes in MySQL, then you'll want to look at adjusting the SQL statement, or tuning the database. If it's somewhere in between, well, pick one, and if that doesn't get enough time out to be acceptable, tune the other side, and keep going back and forth 'till it meets your goal time.

[reply]

In Section Seekers of Perl Wisdom