I have just moved a WP installation from one hosting provider to another. Everything went fine except for a problem I have with the new installation. Please note that I have moved from a regular VPS to a kinda powerful and fast dedicated machine.
The thing is that now, the website is slower than when in the previous server. It takes 6-7 seconds to load a page and according to Chrome's Dev Tools network panel, it has a period of 3-4 seconds to the get the first response byte (TTFB), which is insane.
I have tried the following with no success:
Review database for anomalies
Disable all plugins (and delete them)
Disable template (and delete it)
With these last two actions, I lowered the loading time to 5-6 seconds, which is a lot for small site (a few hundreds of posts and 50-60 pages), with no comments enabled. I still have the 3-4 TTFB period.
After that, I installed the Query Monitor plugin and found out that, at every page load, WP performs hundreds (ranging from 400 to 800) database queries and, in some cases, even 1500 database queries. OMG!
Honestly, I am quite lost here. I mean, on one hand I have this strange database behavior I cannot really understand. And on the other hand, I cannot help wondering how it was faster on the previous & slower server.
By the way, I have moved from MySQL to MariaDB, which should be even faster too. Indexes are kept when dumping & importing the file. I am lost. :(
Any help is greatly appreciated. Apologies for my english (not my language) and please let me know if the is some important information missing. I will be glad to provide all the necessary information that help me/us troubleshoot this.
Thanks in advance!
I think you should optimize your MySQL config (my.cnf in Linux or my.ini in Windows). To view problems in MySQL you can try run the script MySQLTuner: https://github.com/major/MySQLTuner-perl.
Related
I'm working on Aegir for migrating/cloning sites from platform1/db1 to platform2/db2. Platform1, platform2, db1 and db2 are verified successfully, but when i try to migrate/clone site the tasks spinning for ever. When i go into the server i can see the db is created on db2 and site is created on platform2 but the task is unfinished which is always in progress. I cancelled the task and re verified the platform which din't help.
Is there anything i'm missing or am i doing something wrong?
You might wish to compare site creation times on both servers. It could take as long to migrate a site over as it does creating a site.
If that works (creating a site on db2) I would try and disable unstable/custom modules until it works. It sounds as though something is interfering.
(Btw in my opinion you shoud post at least the last lines of the task log, as well as how long you waited and how big the site's backups are, and any relevant info on the db engines etc. I notice you forgot to talk about installs on db2 too.)
One of the projects I'm working on is suffering from a recent slowdown in the DB (since last week).
Code hasn't changed, data may have changed a little but not significantly so at this stage I'm just exploring DB configuration (as we are on a managed hosting platform, end have had some similar issues in the past).
Unfortunately I'm out of my depth a bit... could anyone please take a look at the output from SHOW STATUS below and see if any of it sets alarm bells off? The only thing I've spotted so far is that key_reads vs key_read_requests don't seem quite right.
Our setup is 2 servers replicated, with all reads done from the slave. Queries which run in 0.01 secs on the master are taking up to 7 secs on the slave... and this has only started recently.
All tables are MyIsam and inserts/updates are negligible (updates happen out of hours). Front end is an ASP .NET website (.NET 4) running on IIS8 with a devart component for data access.
Thanks!
SHOW STATUS output is here: http://pastebin.com/w6xDeD48
Other factors can impact MySQL performance:
virus scanning software -> I had a issue with McAfee bogging out peformance due to it scanning temporary table files
Other services running on server?
Have you tried a EXPLAIN SELECT on the query? This would given you an indication of the index size. As #Liath indicated the indexes may be out of date on the slave but find on the master.
Just an update in case it ever helps anyone else in future - it looks like the culprit might be the query cache for now, as we are seeing better performance with it turned off (still not quite as good as we had before the issue).
So we will try to tune it a little and get back to great performance!
I have an 600ish-line perl script, not written by me but used with permission, that parses a set of xml files and inserts them into a few MySQL tables. I ran this script on my machine first back in May or so, and everything seemed fine; it was fast enough for my purposes (multiple insert queries per second), worked great. I recently acquired more data that needed the same parsing, so I was going to run it again. This time, it was glacially slow - 10-12 seconds per query.
No hardware changed in the interim; the only significant software change made was "upgrading" to Windows 8.1, when it was on 8.0 originally. Could that be the cause of the problem? Anyone know how I might troubleshoot this? At this pace, it's literally going to take three months to complete.
I'm happy to provide some/all of the script upon request, as well as any other details you might want.
Thanks in advance!
To diagnose the performance problem in your script, consider installing and using tools such as the following:
Devel::NYTProf. This excellent profiler toolkit will show you exactly where you're spending cycles executing Perl code. By design, it leaves out time spent in I/O, including database calls.
DBI::Profile. This offers multiple levels of debug profiling, and can show you how long each database action takes. It's an excellent companion to Devel::NYTProf and easy to use.
If neither Devel::NYTProf nor DBI::Profile show a hotspot in your code (either in a perl computation or a database query / transaction), then you should look through your code for system calls or network accesses to see if those are the culprits.
i installed an joomla website on an vps with nginx+php-fpm, mysql....with low traffic
everything load pretty fast; except the generated joomla page because of slow mysql querys. is there a way to cache/speed them up?
mysql query does not work because there is a low traffic(maybe an user/one hour)
I've built a lot of sites with Joomla (although admittedly not paired with nginx) and never had to even consider this. How much content does your installation have? It would have to be an awful lot before any serious thought needed to be given to database tuning.
Are you sure the database engine is the cause of the problem? You can verify this by turning on the debug output in Joomla's global configuration (under 'System'), which will show the queries and some timing info in the footer. Don't forget to turn it off when you're done with it!
Have a look at the timing for the Application afterRender entry. Unless you're consistently seeing multi-second values there, I'd be looking elsewhere for your problem.
There is an action in the admin section of a client's site, say Admin::Analytics (that I did not build but have to maintain) that compiles site usage analytics by performing a couple dozen, rather intensive database queries. This functionality has always been a bottleneck to application performance whenever the analytics report is being compiled. But, the bottleneck has become so bad lately that, when accessed, the site comes to a screeching halt and hangs indefinitely. Until yesterday I never had a reason to run the "top" command on the server, but doing so I realized that Admin::Analytics#index causes mysqld to spin at upwards of 350+% CPU power on the quad-core, production VPS.
I have downloaded fresh copies of production data and the production log. However, when I access Admin::Analytics#index locally on my development box, while using the production data, it loads in about 10 - 12 seconds (and utilizes ~ 150+% of my dual-core CPU), which sadly is normal. I suppose there could be a discrepancy in mysql settings that has suddenly come into play. Also, a mysqldump of the database is now 531 MB, when it was only 336 MB 28 days ago. Anyway, I do not have root access on the VPS, so tweaking mysqld performance would be cumbersome, and I would really like to get to the exact cause of this problem. However, the production logs don't contain info. on the queries; they merely report the length that these requests took, which average out to a few minutes apiece (although they seemed to have caused mysqld to stall for much longer than this and prompting me to request our host to reboot mysqld just to get our site back up in one instance).
I suppose I can try upping the log level in production to solicit info. on the database queries being performed by Admin::Analytics#index, but at the same time I'm afraid to replicate this behavior in production because I don't feel like calling our host up to restart mysqld again! This action contains a single database request in its controller, and a couple dozen prepared statements embedded in its view!
How would you proceed to benchmark/diagnose and optimize/fix this action?!
(Aside: Obviously I would like to completely replace this functionality with Google Analytics or a similar solution, but I need fix this problem before proceeding.)
I'd recommend taking a look at this article:
http://axonflux.com/building-and-scaling-a-startup
Particularly, query_reviewer and newrelic have been a life-saver for me.
I appreciate all the help with this, but what turned out to be the fix for this was to implement a couple of indexes on the Analytics table to cater to the queries in this action. A simple Rails migration to add the indexes and the action now loads in less than a second both on my dev box and on prod!