[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
===================
|
|
|
|
|
Profiling Odoo code
|
|
|
|
|
===================
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
This tutorial requires :ref:`having installed Odoo <setup/install>`
|
|
|
|
|
and :doc:`writing Odoo code <backend>`
|
|
|
|
|
|
|
|
|
|
Graph a method
|
|
|
|
|
==============
|
|
|
|
|
|
2021-05-31 16:33:32 +07:00
|
|
|
Odoo embeds a profiler of code. This embedded profiler output can be used to
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
generate a graph of calls triggered by the method, number of queries, percentage
|
|
|
|
|
of time taken in the method itself as well as the time that the method took and
|
|
|
|
|
its sub-called methods.
|
|
|
|
|
|
|
|
|
|
.. code:: python
|
|
|
|
|
|
|
|
|
|
from odoo.tools.misc import profile
|
|
|
|
|
[...]
|
|
|
|
|
@profile('/temp/prof.profile')
|
|
|
|
|
@api.multi
|
|
|
|
|
def mymethod(...)
|
|
|
|
|
|
|
|
|
|
This produces a file called /temp/prof.profile
|
|
|
|
|
|
|
|
|
|
A tool called *gprof2dot* will produce a graph with this result:
|
|
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
|
|
|
|
gprof2dot -f pstats -o /temp/prof.xdot /temp/prof.profile
|
|
|
|
|
|
|
|
|
|
A tool called *xdot* will display the resulting graph:
|
|
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
|
|
|
|
xdot /temp/prof.xdot
|
|
|
|
|
|
|
|
|
|
Log a method
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
Another profiler can be used to log statistics on a method:
|
|
|
|
|
|
|
|
|
|
.. code:: python
|
|
|
|
|
|
|
|
|
|
from odoo.tools.profiler import profile
|
|
|
|
|
[...]
|
|
|
|
|
@profile
|
|
|
|
|
@api.model
|
|
|
|
|
def mymethod(...):
|
|
|
|
|
|
|
|
|
|
The statistics will be displayed into the logs once the method to be analysed is
|
|
|
|
|
completely reviewed.
|
|
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
|
|
|
|
2018-03-28 06:18:23,196 22878 INFO openerp odoo.tools.profiler:
|
|
|
|
|
calls queries ms
|
|
|
|
|
project.task ------------------------ /home/odoo/src/odoo/addons/project/models/project.py, 638
|
|
|
|
|
|
|
|
|
|
1 0 0.02 @profile
|
|
|
|
|
@api.model
|
|
|
|
|
def create(self, vals):
|
|
|
|
|
# context: no_log, because subtype already handle this
|
|
|
|
|
1 0 0.01 context = dict(self.env.context, mail_create_nolog=True)
|
|
|
|
|
|
|
|
|
|
# for default stage
|
|
|
|
|
1 0 0.01 if vals.get('project_id') and not context.get('default_project_id'):
|
|
|
|
|
context['default_project_id'] = vals.get('project_id')
|
|
|
|
|
# user_id change: update date_assign
|
|
|
|
|
1 0 0.01 if vals.get('user_id'):
|
|
|
|
|
vals['date_assign'] = fields.Datetime.now()
|
|
|
|
|
# Stage change: Update date_end if folded stage
|
|
|
|
|
1 0 0.0 if vals.get('stage_id'):
|
|
|
|
|
vals.update(self.update_date_end(vals['stage_id']))
|
|
|
|
|
1 108 631.8 task = super(Task, self.with_context(context)).create(vals)
|
|
|
|
|
1 0 0.01 return task
|
|
|
|
|
|
|
|
|
|
Total:
|
|
|
|
|
1 108 631.85
|
|
|
|
|
|
|
|
|
|
Dump stack
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
Sending the SIGQUIT signal to an Odoo process (only available on POSIX) makes
|
|
|
|
|
this process output the current stack trace to log, with info level. When an
|
2021-05-31 16:33:32 +07:00
|
|
|
odoo process seems stuck, sending this signal to the process permit to know
|
[REF][MOV] documentation apocalypse
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
2021-04-30 17:40:29 +07:00
|
|
|
what the process is doing, and letting the process continue his job.
|
|
|
|
|
|
|
|
|
|
Tracing code execution
|
|
|
|
|
======================
|
|
|
|
|
|
|
|
|
|
Instead of sending the SIGQUIT signal to an Odoo process often enough, to check
|
|
|
|
|
where the processes are performing worse than expected, we can use the pyflame tool to
|
|
|
|
|
do it for us.
|
|
|
|
|
|
|
|
|
|
Install pyflame and flamegraph
|
|
|
|
|
------------------------------
|
|
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
|
|
|
|
# These instructions are given for Debian/Ubuntu distributions
|
|
|
|
|
sudo apt install autoconf automake autotools-dev g++ pkg-config python-dev python3-dev libtool make
|
|
|
|
|
git clone https://github.com/uber/pyflame.git
|
|
|
|
|
git clone https://github.com/brendangregg/FlameGraph.git
|
|
|
|
|
cd pyflame
|
|
|
|
|
./autogen.sh
|
|
|
|
|
./configure
|
|
|
|
|
make
|
|
|
|
|
sudo make install
|
|
|
|
|
|
|
|
|
|
Record executed code
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
As pyflame is installed, we now record the executed code lines with pyflame.
|
|
|
|
|
This tool will record, multiple times a second, the stacktrace of the process.
|
|
|
|
|
Once done, we'll display them as an execution graph.
|
|
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
|
|
|
|
pyflame --exclude-idle -s 3600 -r 0.2 -p <PID> -o test.flame
|
|
|
|
|
|
|
|
|
|
where <PID> is the process ID of the odoo process you want to graph. This will
|
|
|
|
|
wait until the dead of the process, with a maximum of one hour, and and get 5
|
|
|
|
|
traces a second. With the output of pyflame, we can produce an SVG graph with
|
|
|
|
|
the flamegraph tool:
|
|
|
|
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
|
|
|
|
flamegraph.pl ./test.flame > ~/mycode.svg
|
|
|
|
|
|
|
|
|
|
.. image:: profile/flamegraph.svg
|