Developer Area/Php profiling: Difference between revisions
From Mahara Wiki
< Developer Area
(4 intermediate revisions by the same user not shown) | |||
Line 9: | Line 9: | ||
The first thing we need to do is installed Xdebug php extension to get the data of Mahara's php scripts. This extension can also be used for debugging php code well, but I will only add the instructions fro profiling here. | The first thing we need to do is installed Xdebug php extension to get the data of Mahara's php scripts. This extension can also be used for debugging php code well, but I will only add the instructions fro profiling here. | ||
=== install extension === | |||
''sudo apt-get install php-xdebug'' | ''sudo apt-get install php-xdebug'' | ||
Check the extension is there <br> | |||
''php -m | grep xdebug'' | |||
''php -m | grep xdebug''<br> | |||
On php.ini you need to add the following lines<br> | |||
''xdebug.remote_enable = 1''<br> | ''xdebug.remote_enable = 1''<br> | ||
''xdebug.remote_autostart = 1''<br> | ''xdebug.remote_autostart = 1''<br> | ||
''zend_extension = /usr/lib/php/20170718/xdebug.so''<br> | ''zend_extension = /usr/lib/php/20170718/xdebug.so''<br> | ||
you should check where is the xdebug.so in your machine | you should check where is the xdebug.so in your machine | ||
Line 24: | Line 28: | ||
Here you can choose if you want to trace all the php code that is run or only a few scripts by passing an argument to the selected ones. more information on this here https://xdebug.org/docs/profiler | Here you can choose if you want to trace all the php code that is run or only a few scripts by passing an argument to the selected ones. more information on this here https://xdebug.org/docs/profiler | ||
To trace all scripts<br> | |||
Set to 1 to turn it on for every request | |||
<br> | Set to 1 to turn it on for every request<br> | ||
''xdebug.profiler_enable = 0'' | ''xdebug.profiler_enable = 0'' | ||
To trace only the scripts with the parameter, let's use a GET/POST parameter to turn on the profiler<br> | |||
<br> | |||
''xdebug.profiler_enable_trigger = 0'' | ''xdebug.profiler_enable_trigger = 0'' | ||
The GET/POST value we will pass; empty for any value<br> | |||
''xdebug.profiler_enable_trigger_value = ""'' | ''xdebug.profiler_enable_trigger_value = ""'' | ||
Set up the output file name and location<br> | |||
Output cachegrind files to /tmp so our system cleans them up later | Output cachegrind files to /tmp so our system cleans them up later<br> | ||
<br> | |||
''xdebug.profiler_output_dir = "/tmp/profiling"'' | ''xdebug.profiler_output_dir = "/tmp/profiling"'' | ||
<br> | <br> | ||
Line 45: | Line 50: | ||
Don't forget to restart the server<br> | Don't forget to restart the server<br> | ||
''sudo service apache2 restart'' | ''sudo service apache2 restart'' | ||
Line 61: | Line 67: | ||
== Kcachegrind == | == Kcachegrind == | ||
http://kcachegrind.sourceforge.net | |||
Kcachegrind is a tool to display the profiling data in a graphical way. All those numbers and codes that we captured with the xdebug profiling tool can be seen as function calls and graphs. | Kcachegrind is a tool to display the profiling data in a graphical way. All those numbers and codes that we captured with the xdebug profiling tool can be seen as function calls and graphs. | ||
=== | === How to in install === | ||
sudo apt-get install kcachegrind | sudo apt-get install kcachegrind | ||
=== Open the profiling files === | === Open the profiling files === | ||
Once you have the kcachegrind | Once you have the kcachegrind installed, you should be able to open one of the xdebug data generated files. On the kcachegrind application, open one of the 'cachegrind.out' files located in the directory set on xdebug.profiler_output_dir property (php.ini). | ||
You should be seeing something like | |||
[[File:Kcachegrind.png|Kcachegrind example]] | |||
=== How to use it to identify code to refactor === | |||
Here you can see all the function call and the resources consumed by it. In this case I've selected the resource to be 'Time' but you can change that to be 'Memory' at the top bar. | |||
On the left table, the functions can be order by self, and incl. where | |||
* self: cost of the function itself ('Self Cost') | |||
* incl.: cost including all called functions ('Inclusive Cost') | |||
You can play with this to identify which functions have the higher cost and should be looked into. Take into consideration that this method will not differentiate between Mahara code and third party library functions. There's not much we can do about the cost of the third party function calls but we can check how many times they are being called by our code. | |||
On the right side we have the graph view, here we have the sequence of function calls and how many times they are executed. We should be paying attention to the call that have great cost (% of the total cost) and are repeated many times. | |||
More information of how to use this application and what the settings mean can be found [http://kcachegrind.sourceforge.net/html/Documentation.html here] | |||
=== Common error === | |||
* I've set up the Xdebug tool for profiling but the 'cachegrind.out' are not generated. | |||
Check the permissions. The browser should be able to access and to write. |
Latest revision as of 16:44, 24 July 2020
What is profiling
Profiling is a method that is used to detect performace issues. For this we use tools to record stack traces of the running program to later be analysed
The install and configuration instructions work on Ubuntu 18.04
Xdebug
The first thing we need to do is installed Xdebug php extension to get the data of Mahara's php scripts. This extension can also be used for debugging php code well, but I will only add the instructions fro profiling here.
install extension
sudo apt-get install php-xdebug
Check the extension is there
php -m | grep xdebug
On php.ini you need to add the following lines
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
zend_extension = /usr/lib/php/20170718/xdebug.so
you should check where is the xdebug.so in your machine
Add the setting for xdebug profiling
Here you can choose if you want to trace all the php code that is run or only a few scripts by passing an argument to the selected ones. more information on this here https://xdebug.org/docs/profiler
To trace all scripts
Set to 1 to turn it on for every request
xdebug.profiler_enable = 0
To trace only the scripts with the parameter, let's use a GET/POST parameter to turn on the profiler
xdebug.profiler_enable_trigger = 0
The GET/POST value we will pass; empty for any value
xdebug.profiler_enable_trigger_value = ""
Set up the output file name and location
Output cachegrind files to /tmp so our system cleans them up later
xdebug.profiler_output_dir = "/tmp/profiling"
xdebug.profiler_output_name = "cachegrind.out.%p"
Don't forget to restart the server
sudo service apache2 restart
If you made it work, you'll get files named cachegrind.out.* in the directory /tmp/profiling. These will contain data that looks like this
fl=(158)
fn=(765)
1409 2 0
cfl=(1)
cfn=(564)
calls=1 0 0
1410 0 160
So we will need another application to display this information in human friendly way.
Kcachegrind
http://kcachegrind.sourceforge.net
Kcachegrind is a tool to display the profiling data in a graphical way. All those numbers and codes that we captured with the xdebug profiling tool can be seen as function calls and graphs.
How to in install
sudo apt-get install kcachegrind
Open the profiling files
Once you have the kcachegrind installed, you should be able to open one of the xdebug data generated files. On the kcachegrind application, open one of the 'cachegrind.out' files located in the directory set on xdebug.profiler_output_dir property (php.ini). You should be seeing something like
How to use it to identify code to refactor
Here you can see all the function call and the resources consumed by it. In this case I've selected the resource to be 'Time' but you can change that to be 'Memory' at the top bar.
On the left table, the functions can be order by self, and incl. where
- self: cost of the function itself ('Self Cost')
- incl.: cost including all called functions ('Inclusive Cost')
You can play with this to identify which functions have the higher cost and should be looked into. Take into consideration that this method will not differentiate between Mahara code and third party library functions. There's not much we can do about the cost of the third party function calls but we can check how many times they are being called by our code.
On the right side we have the graph view, here we have the sequence of function calls and how many times they are executed. We should be paying attention to the call that have great cost (% of the total cost) and are repeated many times.
More information of how to use this application and what the settings mean can be found here
Common error
- I've set up the Xdebug tool for profiling but the 'cachegrind.out' are not generated.
Check the permissions. The browser should be able to access and to write.