1 Profiling and performance |
|
2 ========================= |
|
3 |
|
4 If you feel that one of your pages takes more time than it should to be |
|
5 generated, chances are that you're making too many RQL queries. Obviously, |
|
6 there are other reasons but experience tends to show this is the first thing to |
|
7 track down. Luckily, CubicWeb provides a configuration option to log RQL |
|
8 queries. In your ``all-in-one.conf`` file, set the **query-log-file** option:: |
|
9 |
|
10 # web application query log file |
|
11 query-log-file=~/myapp-rql.log |
|
12 |
|
13 Then restart your application, reload your page and stop your application. |
|
14 The file ``myapp-rql.log`` now contains the list of RQL queries that were |
|
15 executed during your test. It's a simple text file containing lines such as:: |
|
16 |
|
17 Any A WHERE X eid %(x)s, X lastname A {'x': 448} -- (0.002 sec, 0.010 CPU sec) |
|
18 Any A WHERE X eid %(x)s, X firstname A {'x': 447} -- (0.002 sec, 0.000 CPU sec) |
|
19 |
|
20 The structure of each line is:: |
|
21 |
|
22 <RQL QUERY> <QUERY ARGS IF ANY> -- <TIME SPENT> |
|
23 |
|
24 CubicWeb also provides the **exlog** command to examine and summarize data found |
|
25 in such a file: |
|
26 |
|
27 .. sourcecode:: sh |
|
28 |
|
29 $ cubicweb-ctl exlog < ~/myapp-rql.log |
|
30 0.07 50 Any A WHERE X eid %(x)s, X firstname A {} |
|
31 0.05 50 Any A WHERE X eid %(x)s, X lastname A {} |
|
32 0.01 1 Any X,AA ORDERBY AA DESC WHERE E eid %(x)s, E employees X, X modification_date AA {} |
|
33 0.01 1 Any X WHERE X eid %(x)s, X owned_by U, U eid %(u)s {, } |
|
34 0.01 1 Any B,T,P ORDERBY lower(T) WHERE B is Bookmark,B title T, B path P, B bookmarked_by U, U eid %(x)s {} |
|
35 0.01 1 Any A,B,C,D WHERE A eid %(x)s,A name B,A creation_date C,A modification_date D {} |
|
36 |
|
37 This command sorts and uniquifies queries so that it's easy to see where |
|
38 is the hot spot that needs optimization. |
|
39 |
|
40 Do not neglect to set the **fetch_attrs** attribute you can define in your |
|
41 entity classes because it can greatly reduce the number of queries executed (see |
|
42 :ref:`FetchAttrs`). |
|
43 |
|
44 You should also know about the **profile** option in the ``all-in-on.conf``. If |
|
45 set, this option will make your application run in an `hotshot`_ session and |
|
46 store the results in the specified file. |
|
47 |
|
48 .. _hotshot: http://docs.python.org/library/hotshot.html#module-hotshot |
|
49 |
|
50 Last but no least, if you're using the PostgreSQL database backend, VACUUMing |
|
51 your database can significantly improve the performance of the queries (by |
|
52 updating the statistics used by the query optimizer). Nowadays, this is done |
|
53 automatically from time to time, but if you've just imported a large amount of |
|
54 data in your db, you will want to vacuum it (with the analyse option on). Read |
|
55 the documentation of your database for more information. |
|