What does Wordpress do on just the home page (slow loading)? - php

I have a problem with a wordpress site and I really can't figure out what causes it.
All the pages in the site load perfectly fine, they are quite stuffed with content but the load time is ok and so is memory usage as they have no problem with a 32M memory limit set in wp-settings.php.
The problem comes with the home page. It takes several seconds to load (excluding other content, just the main request) and fails (where 'fails' stands for blank page shown) unless I raise the memory limit above 300M.
Possible suggestion 1: check index.php code
Done. I replaced it with a blank page only containing the word TEST, still same slow loading and blank page.
Possible suggestion 2: disable all plugins
Done. Disabled each and every plugin and still same exact behaviour.
My current workaround
The only thing that I could find to temporarily solve the issue, is redirecting (via wordpress' internal rewrite) any request for / to a custom page which is linked to index.php. This way I have the homepage working fine, quickly and under the 32M memory limit.
Now, this works but it's a horribly dirty hack, so how can I find out what wordpress is doing when I ask for the home page before loading the template given that it has nothing to do with plugins?

If you've tried replacing index.php with just plain text then i would definitely check your .htaccess file for errors, extra characters, or some type of invalid configuration. Disable it and see if that helps for starters.

To see if anything comes out try adding WP_DEBUG=true to wp-config.php
Might show you if something else is erroring earlier
But otherwise yes kachegrind or xdebug definately
Also if on unix and you have access try strace command on the apache process

Not easy to tell, but there is a way to find out: use the xdebug profiler, and then use kcachegrind or its windows port to view its results. It will show you lots of data, including a visual chart, which will hopefully be very helpful in identifying where is PHP spending most of its time...

Is the server itself doing any pre/post processing on the homepage?
Turning on PHP errors may shed some light on the process as will looking at the httpd error log.
Out of curiosity, are you positive your site hasn't been hijacked?

Related

Receiving 403 error when saving Joomla 3.4.8 article with php embedded

I've had this working in the past (earlier version of Joomla), but must have changed something and I can't get it work (even in a brand new site). I'm using Joomla 3.4.8, the newest version of JCE, and DirectPhp.
I have Global Configuration > Text Filter Settings > Super Users set to No Filtering, and have adjusted JCE Administration > Editor Profiles > Default > Editor Parameters > Advanced > Allow PHP to yes.
Yet, when I save a any article with Php code I get a 403 error. Without the php code it saves correctly.
Does anybody have any hints?
Many of our clients are facing the same problem. It turned out it is related to their host forcing browser caching on non-static content. Please follow the guide here ( http://www.itoctopus.com/how-to-disable-browser-caching-in-joomla-backend ) and add the appropriate code to the .htaccess file to prevent browser caching. Please post back here if it fixes your problem or not.
One way around this that I worked out was to edit the php code in PHPmyAdmin directly.
It seems that mod_security on your apache server is causing the error to be forced when either your code is bad or is restricted. (this is not a bad thing as it stops hacking attempts on your site really.)
Going through phpMyAdmin requires a bit more skill but works all the same.
Anyway that is what I do now when I encounter this issue. (the hard part is finding what is causing the error in the first place)
Probably mod_security is set to block PHP injection attacks, and it sees that as one. The way to tell is check the apache error log and the mod security audit log. Then, if you have access to the config files, you can configure an exception based around either that url or that variable to whitelist it from PHP injection checks.
WARNING: If you do that, be sure the code handling that form will be able to defend itself from injections, because you just stopped apache from defending it.
But the best solution for this is to write a plugin you can invoke from the content item, rather than inject all that code into your content. Makes it easier to maintain -- changes are localized instead of scattered across lots of database records. Change the plugin once and every page that needs it gets the change, instead of having to touch each and every item in the db to make that same change.
PS: There's a Joomla Stack Exchange. Check the list (top right, at time of writing).

Finding a bottleneck when loading a webpage?

UPDATE 1:
After doing an strace on the server, I have discovered that the mmap's process is taking 90% of this processing time. I've discoverd that 1 of the pages is taking a minute to load.
So I found this link:
PHP script keeps doing mmap/munmap
It possibly shows the same problem. However, I don't understand what the anwer means by correctly disabling the php error handlers?
ORIGINAL QUESTION:
How do I check for bottle necks on my web server when loading a specific web page which is being served by my server?
For some reason, a couple of pages on my site have become very slow, and I am not sure where the slowness is happening.
Screenshot from Chrome Dev Tools:
Click here to enlarge:
So basically, I need to find out what is taking this section to long to load? Client Side web tools can't seem to break this down?
Xdebug: Profiling PHP Scripts - pay attention to KCacheGrind tool or, alternatively, you can use Advanced PHP debugger apd_set_pprof_trace() function and pprofp to process generated data file.
Derick Rethans (author of Xdebug) released quite a nice article today called What is PHP doing?
It covers the strace that you've already done, but also shows you how you can use a custom .gdbinit to get the actual php function name that is causing the problem.
Of course you have to run your script from the command line with gdb, so I hope that your problem is reproducible in this way.
mmap is for creating a memory mapped view of a file.
If it really is the error handler causing it, I'd guess that your script is generating a lot of errors (which you are trying to log), maybe a NOTICE for an undefined index in a loop or something).
Check the log file (is anything being logged at all?), check permissions on the log file if nothing is logged, also double check what your error reporting level is set to.
var_dump(ini_get('error_reporting') & E_NOTICE); - Non-zero if you are reporting notices.
error_reporting(E_ALL & ~E_NOTICE); - Turn off reporting notices.
I would suggest looking into Xdebug profiling. The other two answers deal with client side loading issues but if your bottleneck is server side it won't become apparent from the use of those tools.
You may also want to look into the database queries that are being run to serve the pages in question. You could be missing an index somewhere which would explain a recent slowness with specific pages as your database tables grow in size.
I would extract those queries and run them using MySQL EXPLAIN (assuming you are using MySQL) to see if there is slowness there.
Using an application such as Fiddler or YSlow Firefox addin will help identify slow loading elements in your website. This should make any issues apparent.
http://fiddler2.com/fiddler2/
https://addons.mozilla.org/en-US/firefox/addon/yslow/
Hope this helps
Page Speed for Chrome is also an option:
https://developers.google.com/speed/docs/insights/using_chrome

Wordpress wp-cron.php looping and overloading server resources

I am working on a site now that seems to have an infinite loop for the wp-cron.php file. My host recently limited my account because they said that a certain query to my database was creating 1GB of error logs every 15 seconds. I am not sure why this is happening.
I wanted to know if anyone has encountered and successfully solved this issue. We were working on this site on a dev server with no problems, but now since we've moved to our production environment we've been getting this issue. I am thinking that maybe some files were lost in the transfer, however it does not seem so.
Thanks
OK So I have found a solution for this, and I figure that it would help to let everyone on here know as well.
Basically, after a lot of research, I have found that the MailChimp Archives plugin apparently fires off the naughty cron job in question every time someone visits the site. For whatever reason, it got thrown into an infinite loop which was creating huge log files (64MB in about 3 seconds). Once I discovered exactly where the issue was coming from, I did the following:
Disabled the plugin
Found a Wordpress function that removes selected hook that schedules the runaway cron job (http://codex.wordpress.org/Function_Reference/wp_clear_scheduled_hook).
Used that function to remove the hook in question, by inserting it into my theme's functions.php file, and reloading the page.
Removed the function once I reloaded the page a few times.
Found the corresponding data in the database, which was in the wp_options table. I just searched the name of that same hook that caused the problem, and found that the option value field contained 9.5MB of text in it! Obviously the cause of the massive slowdown, since this 9.5MB of text needed to be loaded and parsed every time someone visited the page. I removed this completely from the database.
Once this was done, I started to notice incremental increases in performance on my Wordpress site over about a half hour or so. I also did another test to see if the log files were accumulating, and they were now only fluctuating between 3-4Kb, which was way better.
I hope this helps. Even though this seems to be a fairly common problem, I don't see many detailed solutions for it, so let this be the first.
Thanks
I believe there was an issue where if the server would go into an infinite loop if you didn't have the wp_cron.php file, since returning the error calls the file again. It's worth checking for in this case.
It's also possible that a variant might be happening - you try to access a file from wp-cron, and the file isn't found.
Even if all the files were copied, their paths might not have been copied correctly.
The cron jobs of Wordpress were causing a high CPU consumption on the server. Even defining define ('DISABLE_WP_CRON', 'true'); does not work. Without using a plugin the way I found it was to include this in the theme's functions.php:
global $wpdb;
$wpdb->update("wp_options", array("option_value"=>""), array("option_name"=>"cron"));

PHP Includes not loading in WordPress

We have a site that we have built in WordPress that is having some issues. When you land on the home page of the site there are certain include files that do not load upon first landing on the page and it also happens intermittently throughout viewing this page. I would like to know it there is a good way to debug these includes (no errors in PHP log) or what best practice would be to trace down this issue. I am at a loss.
I know WP hooks are recommended over includes but this theme was passed off to us using hooks.
Note: Firebug Console does not provide any errors.
Any and all advice is greatly appreciated, I am lost with this one.
This can be a memory problem with PHP. Try increasing PHP's memory_limit setting to 64M. Put the following inside .htaccess:
php_value memory_limit 64M
Also validate your HTML and see if there are any errors like unclosed divs.
Check your javascripts for anything that can remove parts of your content dynamically.
You could run it using something like xdebug to give you a better idea of what is going on.
An easier alternative would be to turn error reporting on so you can see what is happening on page rather than trawling through error logs:
ini_set('display_errors',1);
error_reporting(E_ALL|E_STRICT);
Put those at the top of load.php

Php.ini Causing Ajax To Load Slow?

Strange bug here... ajax has been loading slow on this server since day one... we thought it was the internet connection, until yesterday. I accidentally added an invalid extension into the php.ini file (ie. extension=php_pdf.dll), and then all of a sudden, the ajax loaded extremely fast. When I took out that invalid extension, the ajax loaded slow again. My colleges and I did not create the php config file, so I'm not sure why this is happening... maybe there's a setting turned on in the php config file that is causing the ajax to load slow, and when this invalid extension is included, it skips the setting... not sure. But hopefully someone can help explain this!
If anyone can point me in the right direction to why this is happening, I'd appreciate it! Our slow ajax loading won't be fixed until this is sorted out, and the guy who created the php.ini file no longer works here.
The site is: link text
So if you click there, you'll see how slow the ajax loads. Please help, I can include the php.ini file if anybody wants to see what settings are enabled.
Thanks in advance to any help I receive.
You may want to install firebug if you are not using it already (it's a webdeveloper plugin for firefox).
I just checked out the site and the data seems to be loading fast enough but it seems the JS is just terribly slow. A hint that something is wrong is also in the net tab that doesn't seem to be able to determine the size of your ajax calls, if the js has that same problem it could cause it to hang waiting for the stream to end.
Looks like misconfiguration in the php.ini, but without its content it is hard to say anything about it really.
Also, if you try to load the ajax call manually, you'll see that the page loads for a long time, but the data shows up almost instantly, and then the connection is not closed immediately.
If you are sure the commenting out of the bad dll declaration is having a bearing on this issue, you could try moving it down the list till you find out which other dll is causing the problem.
Did you look in the php start up errors?
ini_set('display_errors','1');
ini_set('display_startup_errors','1');
error_reporting (E_ALL);

Categories