![]() ![]() It’s now unlocked and my WordPress back-end is working at sub-second speeds again. Turns out, in this case, my server had been updating so many products that the datafeedr website had automatically banned my site! That means I instantly know where to go look to fix this problem. Working from the top downwards, you can see 2 calls to curl_exec – made by the DatafeedrAPI plugin in the datafeedr.php file. Using XDebug Profiler and QCacheGrind I got this image: Get it for Linux or Windows (for Windows I use QCacheGrind) and download the cachegrind.out.* file(s) to your computer to analyse them and figure out where your poor performance is coming from.įor example, I was getting an elusive 90 second page load on my widgets page on one of my sites. You can analyse this data with the visual tool KCacheGrind. You will get a whole bunch of profiling data saved to /var/log/xprofiler. Visit one of your problem website pages and append the following parameter to the URL: ?XDEBUG_PROFILE=secretpassword For more in-depth information check this page out: Using XDebug profiler to figure out why a WordPress page is slow Obviously make sure you have enough space because this will dump a lot of data to disk. If you don’t want to use the URL trigger and instead want to profile everything that happens on your server, you can modify the following setting in php.ini: xdebug.profiler_enable = 1Īnd set your profiler_enable_trigger value back to 0. Restart the php7.0-fpm service with this command: service php7.0-fpm restart Get XDebug profiler to run all the time Save the file and then make sure you create the folder and change the owner so PHP can write to it: mkdir /var/log/xprofilerĬhown www-data:www-data /var/log/xprofiler Make sure and choose some other characters for the secret password – the xprofiler saves a LOT of information to disk (if you set the profiler_output_name as above), so if a nasty robot finds your site and adds this parameter it could bring your site down very quickly. If you do not wish to have a lot of log files, then don’t do this and you’ll only ever have as many log files as you have PHP processes. Note: I set profiler_output_name because the default is cachegrind.out.%p – the %p is the processid, so when the same PHP-FPM process gets used again for serving up another request the previous log file will be overwritten. Xdebug.profiler_enable_trigger_value = secretpassword Xdebug.profiler_output_name = cachegrind.out.%t.%p Now edit: /etc/php/7.0/fpm/php.ini (and optionally /etc/php/7.0/cli/php.ini), find the modules area and insert the following lines: zend_extension = /usr/lib/php/20151012/xdebug.so This page will then tell you how to install it, specifically for your server.įor my servers, installation looks like this: wget Ĭp modules/xdebug.so /usr/lib/php/20151012 ![]() Then grab the contents of that phpinfo.txt file and paste them into this web page: In the meantime, feel free to dig into the other available profiling tools. We will focus on Xdebug in this post, and I may release a second post about Blackfire later. Using XDebug profiler to figure out why a WordPress page is slow In the PHP ecosystem, there are several tools available to perform code profiling.Get XDebug profiler to run all the time. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |