|
|
Sponsored Content
The Lounge
What is on Your Mind?
MySQL Performance Problems
Post 303041393 by Neo on Friday 22nd of November 2019 06:14:47 AM
11-22-2019
Administrator
I just completed (for the most part) a database optimization which was slowing the site down.
In a nutshell, when I created some new code to mitigate against Google soft 404 "errors" (slim content) by adding matching man pages to posts with very little content, I used a "real time" FULLTEXT search of over 350K man pages, and this was causing some performance issues.
Plus, my new code worked, and Google search referrals have just about doubled since I created the solution, but the upside/downside was that the site traffic also doubled (which is a good thing) and the new queries were killing performance (a bad thing).
In the final optimization, I preprocessed all these matches and stored the results in the DB (the ids of all the man pages which match the discussion contents) so, the long MySQL queries doing these FULLTEXT NATURAL LANGUAGE searches on the fly were eliminated (right now about 99.5+ are gone, I have about a half a day of processing to get to 99.999 percent.
The performance improvement is remarkable and the site is much faster, and I have earned my black belt (or at least a brown belt) in MySQL performance tuning, after all these years.
In a nutshell, when I created some new code to mitigate against Google soft 404 "errors" (slim content) by adding matching man pages to posts with very little content, I used a "real time" FULLTEXT search of over 350K man pages, and this was causing some performance issues.
Plus, my new code worked, and Google search referrals have just about doubled since I created the solution, but the upside/downside was that the site traffic also doubled (which is a good thing) and the new queries were killing performance (a bad thing).
In the final optimization, I preprocessed all these matches and stored the results in the DB (the ids of all the man pages which match the discussion contents) so, the long MySQL queries doing these FULLTEXT NATURAL LANGUAGE searches on the fly were eliminated (right now about 99.5+ are gone, I have about a half a day of processing to get to 99.999 percent.
The performance improvement is remarkable and the site is much faster, and I have earned my black belt (or at least a brown belt) in MySQL performance tuning, after all these years.
This User Gave Thanks to Neo For This Post:
|
|
4 More Discussions You Might Find Interesting
1. AIX
... a disk drive to be 100% busy?
hdisk0 100.0 1.3K 342.7 1.3K 22.0 PgspIn 651 % Noncomp 75.5
hdisk1 100.0 1.3K 320.2 1.2K 20.0 PgspOut 6 % Client 75.5
It's really slowing down performance on my system and I would like to know what is causing this.
... (2 Replies)
Discussion started by: bbbngowc
2 Replies
2. SCO
hi
We have migrated SCO 5.0.6 into ESX4, but the VM eats 100% of the virtual CPU.
Here is top print from the SCO VM:
last pid: 16773; load averages: 1.68, 1.25, 0.98 02:08:41
79 processes: 75 sleeping, 2 running, 1 zombie, 1 onproc
CPU states: 0.0% idle, 17.0% user,... (7 Replies)
Discussion started by: ccc
7 Replies
3. AIX
Hello,
I encounter some performance issues on my AIX 5.3 server running in a LPAR on a P520. How do I investigate performance issues in AIX. Is there any kind of procedure that takes me to the steps to investigate my server and find the sub systems that is causing the issues?
The performance... (1 Reply)
Discussion started by: petervg
1 Replies
4. Programming
I need to rotate a pixmap in XLib with some kind of interpolation to reduce the aliasing.
I came up with the following code, which uses bilinear interpolation. It works fine: the rotated image looks perfect, but unfortunately it takes 5 or 6 seconds for each rotation. (in a 300x300, 16 colours... (5 Replies)
Discussion started by: mghis
5 Replies
LEARN ABOUT DEBIAN
grass-mesql
grass-mesql(1grass) Grass User's Manual grass-mesql(1grass) NAME
grass-mesql - MySQL embedded driver MySQL embedded driver MySQL embedded driver in GRASS MySQL database driver in GRASS enables GRASS to store vector attributes in MySQL embedded database without necessity to run MySQL server. Driver and database name GRASS modules require 2 parameters to connect to a database. Those parameters are 'driver' and 'database'. For MySQL embedded driver the parameter 'driver' should be set to value 'mesql'. The parameter 'database' is a full path to the directory where database tables are stored. The best place is a directory in the mapset. The directory must be created before use of the driver. In the name of database it is possible to use 3 variables: $GISDBASE - path to current GISBASE $LOCATION_NAME - name of current location $MAPSET - name of current mapset Examples of connection parameters: db.connect driver=mesql database='$GISDBASE/$LOCATION_NAME/$MAPSET/mysql' db.connect driver=mesql database=/home/user1/db Data types, indexes For more informations about supported data types and indexes see the documentation for MySQL (mysql) driver Database type Because database closing was found very slow if InnoDB was used, the InnoDB storage is disabled by default (hardcoded '--skip-innodb' server option). Note The embedded server is started with hardcoded '--bootstrap' option to avoid warning about missing mysql.time_zone_leap_second table. This can be fixed in future. SEE ALSO
db.connect, SQL support in GRASS GIS Credits Development of the driver was sponsored by Faunalia (Italy) as part of a project for ATAC. AUTHOR
Radim Blazek Last changed: $Date: 2011-02-07 18:59:50 +0100 (Mon, 07 Feb 2011) $ Help Index GRASS 6.4.2 grass-mesql(1grass)