fec00da16e8e4a0266acf936c16e2a052d9dbd5a
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Romain Derie
|
d348bed1ad |
[IMP] website, *: use upsert to improve visitor perf
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closes odoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
|
||
|
Aurélien Warnon
|
a0d33b1c29 |
[IMP] website[_event|_crm]: unlink visitors when inactive & enforce linked visitors
PURPOSE Visitors are useful in terms of marketing analysis but they can bloat the database really quickly if you have a lot of traffic on your website. This commit aims to relieve the database by fully deleting inactive visitors. SPECS On an active website, you can easily reach hundreds or even thousands of visitors per day. While active visitors are useful for marketing purposes, inactive ones were archived after a period of inactivity (i.e: not connected for X days in a row, where X is configurable as a parameter and 30 by default). But archiving visitors is not really useful either. We don't see any specific cases where you would want to restore some visitors. That means we are better off unlinking the visitors completely to save database storage space. We want to make exceptions and avoid deletion of inactive visitors in some cases: - When they are linked to a partner (meaning most likely linked to a registered user) - When they are linked to leads - When they are registered to events Several tests were added to ensure that leads matching these conditions are not unlinked. We also took this opportunity to enforce the "_link_to_visitor" rules in those tests to make sure that: - When visitors are linked, the leads are merged into the main visitor - When visitors are linked, the event tickets are merged into the main visitor - When visitors are linked, the wishlisted tracks are merged into the main visitor This is also preliminary work for a commit that will move the push_token of website.visitors to a separate table. That will in turn allow us to link the push_tokens within the "_link_to_visitor" method and delete the linked visitor instead of archiving it. LINKS Task-2410217 Part-of: odoo/odoo#65113 |
||
|
Thibault Delavallée
|
db19463f25 |
[REF] event(_*): clean tests common files
Purpose is to have a common event class for users and useful stuff (customers, products, ...) but lessen usage of common test data through sub modules. Indeed having a "global event type" test data updated in various addons is actually complicated to maintain. Sub add-ons are updated to use mainly the ``EventCase`` test class holding users and side data. Data specific to those modules (event type with some specific configuration notably) is created and used in tests in the given module only, and not through generic event_type_complex and event_0 test data anymore. With this commit tests are more localized to their add-on and modifying data in a given add-on has less chances to have unwanted side effect in other event submodules unit tests. Task-2703285 (Event performance improvements) Task-2703289 (Event testing and coverage) Part-of: odoo/odoo#81068 |
||
|
Thibault Delavallée
|
777d0d316e |
[IMP] website_event(_track): reorganize tests
Purpose is to merge some tests, clarify naming and reorder files according to their content. Task-2577079 PR odoo#72411 |